Ich musste viel probieren, bis ich zu einer geeigneten Lösung kam. Mein IST Zustand: Ich habe über einen Link eine Slideshow mit der Fancybox geöffnet. In dem iframe befand sich eine „ganz normale“ Seite (eigenes Template in TYPO3). Nun wollte, dass sich die Fancybox auch schließt, wenn ich auf einen bestimmten Link klicke.
Etliche Aufrufe über eine Funktion haben nicht geklappt. Erfolg brachte onclick:
onclick="window.top.$.fancybox.close();"
Danke an Bastian Bringenberg.
Ich konnte es kaum glauben, dass ich so lange an der Lösung eines manuellen (ohne Extension, sondern nur mit TypoScript) printlinks saß. Teilweise waren die Lösungen veraltet (z.B. GPvar anstatt GP) oder nahmen keine Rücksicht auf die Get Variablen von tt_news. Außerdem war es mir wichtig, dass ich nicht direkt über JavaScript ein window.print aufrufe und dann „nur“ noch die print.css genommen wird. Ich wollte ein komplett neues Template, somit eine Druck-Vorschaufunktion für den User und erst dann das automatische OS Druck-Fenster. Das TypoScript kann natürlich nach belieben angepasst werden.
Hiermit erstelle ich den Printlink und später kopiere ich ihn einen Marker.
temp.print-link = COA
temp.print-link {
10 = TEXT
10.value = Seite drucken
stdWrap.wrap = |
stdWrap.typolinkno_cache = 1
stdWrap.typolink.target = print
stdWrap.typolink.ATagParams = target = _top
stdWrap.typolink.parameter.cObject = COA
stdWrap.typolink.parameter.cObject {
5 = TEXT
5.data = page:uid
5.wrap = index.php?id=|
5.required = 1
10 = TEXT
10.value = &no_cache=1
20 = TEXT
20.data = GP:L
20.wrap = &L=|
20.required = 1
30 = TEXT
30.data = GP:tx_ttnews | backPid
30.wrap = &tx_ttnews[backPid]=|
30.required = 1
40 = TEXT
40.data = GP:tx_ttnews | tt_news
40.wrap = &tx_ttnews[tt_news]=|
40.required = 1
50 = TEXT
50.data = GP:cHash
50.wrap = &cHash=|
50.required = 1
60 = TEXT
60.value = &type=98
}
}
Und hiermit definiere ich das Drucktemplate
print = PAGE
print {
typeNum = 98
bodyTag = <body onload="javascript:window.print()">
##disable typo3 index
config.index_enable = 0
##disable google index
headerData.123 = TEXT
headerData.123.value = <meta name="robots" content="noindex, nofollow" />
includeCSS.fileDefault = fileadmin/templates/css/print.css
10 = TEMPLATE
10 {
template = FILE
template.file = fileadmin/templates/print.tmpl
workOnSubpart = DOCUMENT_BODY
marks {
CONTENT < styles.content.get
}
}
}
Stellt man nachträglich die TYPO3 RealURL Konfiguration mit folgendem Befehl 'defaultToHTMLsuffixOnPrev' => false um und erhält dadurch Seiten ohne eine *.html Endung, erscheint für bestehende Links mit der Endung ein Server Error. Das Entfernen der *.html Endung soll aus SEO Sicht vorteilhaft sein. Daher sollte man auf jeden Fall auch eine Weiterleitung einrichten. Diese Weiterleitung leitet dann allgemeingültig alle *.html Dateien zu dem Verzeichnis um. Dies tut man am besten über die htaccess Datei mit folgendem Befehl:
RedirectMatch (.*)\.html$ $1/
Aus http://domain.de/datei.html wird http://domain.de/datei/
Am besten wäre es noch, wenn man alle URLs von http://domain.de/datei auf http://domain.de/datei/ leiten würde, somit jedesmal den endenen Slash (trailing slash) hinzufügen würde. Somit vermeidet man Duplicate Content. Leider hat bei mir u.g. Code nicht funktioniert. Vielleicht weiß jemand Rat?
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_URI} !(\.[a-zA-Z0-9]{1,5}|/)$
RewriteRule (.*)([^/])$ http://domain.de/$1$2/ [R=301,L]
Vielleicht haben es einige von euch bemerkt: Hat man einen geschützten Bereich in TYPO3 (4.5.5) mit feuser und srfeuserregister laufen, außerdem eine Mehrsprachigkeit (in meinem Fall deutsch als default und englisch als id=1) und das 404 Handling an, dann kommt es zu Problemen. Anstatt die Login Maske von feuser aufzurufen, nachdem ein Link zum geschützen Bereich aufgerufen wurde, erscheint eine 404 Seite. Dieses Problem habe ich folgendermaßen mit einer kleinen Funktion behoben:
<?php
define(LOGIN_URL, "http://www.domain.de/login.html");
define(LOGIN_URL_EN, "http://www.domain.de/en/login.html");
define(NOTFOUND_URL, "http://www.domain.de/404.html");
define(NOTFOUND_URL_EN, "http://www.domain.de/en/404.html");
class user_pageNotFound {
function pageNotFound($param, $ref) {
if ($param["pageAccessFailureReasons"]["fe_group"] != array(""=>0)) {
header("HTTP/1.0 403 Forbidden");
if ($_GET['L'] == 1){
$url = LOGIN_URL_EN."?redirect_url=" . $param["currentUrl"];
} else {
$url = LOGIN_URL."?redirect_url=" . $param["currentUrl"];
}
} elseif ((substr($param['currentUrl'], 1, 2)) == "en") {
$url = NOTFOUND_URL_EN;
} else {
$url = NOTFOUND_URL;
}
session_start();
$strCookie = 'PHPSESSID=' . $_COOKIE['PHPSESSID'] . '; path=/';
session_write_close();
$c = curl_init();
curl_setopt($c, CURLOPT_URL, $url);
curl_setopt($c, CURLOPT_COOKIE, $strCookie);
$contents = curl_exec($c);
curl_close($c);
if ($contents) return $contents;
else return FALSE;
}
}
?>
Hierbei wird vor dem 404 Handling auch noch die RealURL abgefragt und je nach Sprache (in meinem Fall „en“) eine andere 404 Seite ausgegeben. Bitte ersetzt oder erweitert diesen Bereich nach euren Anforderungen. Außerdem müssen von euch natürlich auch die vier Konstanten (LOGIN_URL, NOTFOUND_URL..) geändert werden.
Zuvor muss in dem Install Tool oder in der localconf.php folgender Eintrag geändert werden: [FE][pageNotFound_handling] = USER_FUNCTION:fileadmin/scripts/pageNotFoundHandling.php:user_pageNotFound->pageNotFound und natürlich der oben genannte Code in das jeweilige Verzeichnis unter fileadmin in die Datei pageNotFoundHandling.php eingefügt werden.
Da die Nachfrage über die komplette Einbindung von Facebook und Twitter kam, hier nochmal der Code für die Einbindung der Buttons über das TypoScript Template.
Das ganze basiert auf den Anforderung, dass die Buttons auf allen Seiten eingeblendet werden sollen. Ich habe außerdem über eine kleine Extension das Abschalten der Buttons für jede Seite in den Seiteneigenschaften erstellt.
Den Code kann man mit Sicherheit auch für den Google+ Button erweitern.
temp.bookmarks = COA
temp.bookmarks {
5 = TEXT
5.value = <br/>
5.if.isFalse.field = tx_nobookmarks_nobookmarks
10 = COA
10 {
10 = TEXT
10.value (
<div style="float:left">
<a href="http://twitter.com/share" data-count="horizontal" data-lang="de">Tweet</a>
<script type="text/javascript" src="http://platform.twitter.com/widgets.js"></script>
</div>
)
10.if.isFalse.field = tx_nobookmarks_nobookmarks
}
20 = COA
20 {
10 = TEXT
10.typolink.parameter.data = TSFE:id
10.typolink.returnLast = url
10.dataWrap = {TSFE:baseUrl}|
10.rawUrlEncode = 1
wrap (
<iframe src="http://www.facebook.com/plugins/like.php?href=|&layout=standard&show_faces=true&width=450&action=like&colorscheme=light&height=80" scrolling="no" frameborder="0" style="border:none; overflow:hidden; width:450px; height:80px; margin:-2px 0 0 15px;background-color:transparent;" allowTransparency="true"></iframe>
)
}
20.if.isFalse.field = tx_nobookmarks_nobookmarks
}
Die Extension ermöglicht, dass ausschalten der Buttons über die Seiteneigenschaften.
Sie kann hier runtergeladen werden: TYPO3 Extension für die Facebook und Twitter Buttos (deaktiviert obigen Code)
Für WordPress gibt es ja mittlerweile ein Plugin, welches das Thumbnail-Bild für Facebooks Like Button festlegt. Früher hat Facebook das erste Bild im Quelltext als Thumbnail gewählt, heutzutage nimmt Facebook einfach irgendeins; manchmal sogar gar keins!
Ich habe also mal in TYPO3 etwas geTYPOscriptet 😉
Da nie Descriptions gepflegt wurden bei dem Kunden, sollte auch hier die Beschreibung bei den Like Button automatisch generiert werden.
Das Facebook Thumbnail-Bild im like Button, lasse ich über das Content-Element textpic (Text mit Bild) erstellen. Man kann das sicherlich noch erweitern auf CEs mit nur Bild. Außerdem muss das Bild über den Reiter media hochgeladen worden sein. Gibt es das CE nicht oder kein Bild unter media, dann wird auch einfach keins genommen. Der Like Button funtktioniert dann natürlich weiterhin.
temp.metabild = COA
temp.metabild {
10=CONTENT
10.table= tt_content
10.select {
orderBy = sorting
where = CType="textpic"
selectFields = image
max=1
begin=0
languageField = sys_language_uid
}
10.renderObj=COA
10.renderObj {
10 = TEXT
10 {
field = image
stdWrap.dataWrap = <link rel="image_src" href="/uploads/pics/|">
}
}
}
page.headerData.35 < temp.metabild
Für die Beschreibung neben dem Like Button, nutze ich den Meta-Tag Description. Hier werden aus dem ersten CE die ersten 300 Zeichen genommen und in den Meta-Tag geschrieben.
temp.meta = COA
temp.meta {
10=CONTENT
10.table= tt_content
10.select {
selectFields = bodytext
orderBy = sorting
languageField = sys_language_uid
where=colPos=0
max=1
begin=0
}
10.renderObj=COA
10.renderObj{
10=TEXT
10{
field=bodytext
stripHtml=1
crop = 300 | ... | 1
}
}
}
page.headerData.76 < temp.meta
page.headerData.76.wrap = <meta name="description" content="|">
Ich habe außerdem noch die Extension tweet_and_like genutzt. Hier wird jeweils der Twitter-Share Button und der Facebook-Like Button in der LIST Ansicht unter jedem News Artikel eingefügt. Das tolle an der Extension: Der Facebook Like zeigt direkt auf die SINGLE Ansicht. Doch auch hier war es in meinem Fall nötig, die description zu generieren und das Thumbnail festzulegen. Das habe ich so getan:
[globalVar = TSFE:id = 167]
temp.newsImage = COA
temp.newsImage {
wrap=<link rel="image_src" href="/uploads/pics/|">
5=RECORDS
5 {
source = {GPvar:tx_ttnews|tt_news}
source.insertData = 1
tables = tt_news
conf.tt_news >
conf.tt_news = TEXT
conf.tt_news.field = image
}
}
page.headerData.35 < temp.newsImage
[end]
Die ID 167 muss dann natürlich gegen die eigene ID der SINGLE Ansicht ausgetauscht werden.
[globalVar = TSFE:id = 167]
temp.newsDesc = COA
temp.newsDesc {
wrap=<meta name="description" content="|">
5=RECORDS
5 {
source = {GPvar:tx_ttnews|tt_news}
source.insertData = 1
tables = tt_news
conf.tt_news >
conf.tt_news = TEXT
conf.tt_news.field = bodytext
conf.tt_news.stripHtml = 1
conf.tt_news.crop = 300 | ... | 1
}
}
page.headerData.76 < temp.newsDesc
[end]
Möchte man je nach Spalte in TYPO3 die Formatierung der Überschriften (header) von Content Elementen ändern, so hilft einem der TypoScript Code weiter:
temp.stdheader < lib.stdheader
lib.stdheader >
lib.stdheader = CASE
lib.stdheader {
key.field=colPos
1 < temp.stdheader
2 < temp.stdheader
default < temp.stdheader
}
lib.stdheader.default.10.1.fontTag = <h2>|</h2>
lib.stdheader.1.10.1.fontTag = <h2>|</h2>
lib.stdheader.2.10.1.fontTag = <span class="rightLinksHeading">|</span>
Von einem Tag auf den anderen hat eine alte phpwcms Installation keine Inhalte mehr angezeigt. Stattdessen wurde die Seite angezeigt, die besagt, dass noch keine Inhalte eingepflegt sind. Im Backend waren jedoch alle Inhalte sichtbar. Der Übeltäter ist das Datum 01.01.2011 😉 Ich habe wirklich sehr gelacht, als ich das gelesen habe. Aber tatsächlich kommt die alte Installation mit dem überaus neuen Datum nicht zurecht. Grund kann außerdem auch eine zu lange History sein.
Die Lösung des Problems wird hier sehr gut beschrieben.
Ich habe die für mich angenehmste Variante genommen:
Das phpwcmsfixarticledate.php Skript herunterladen entpacken, in das phpwcms root Verzeichnis (dort wo z.B. die login.php liegt) hochladen und einmal aufrufen. Fertisch!
Ich habe soeben ein Update von TYPO3 4.4.6 auf TYPO3 4.5 durchgeführt. Ein paar Tage zuvor habe ich die gleiche Installation von 4.2.3 auf 4.4.6 gebracht. Da sieht man schon einen klaren Unterschied. Merci an alle Entwickler, die das möglich gemacht haben. Das ist ein goßer Meilenstein in Richtung TYPO3 5.
Nun zur Fehlermeldung:
Warning: date() [function.date]: It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'Europe/Berlin' for 'CET/1.0/no DST' instead in /html/typo3_src-4.5.0/t3lib/class.t3lib_div.php on line 5928
Entstanden ist die Fehlermeldung unter PHP 5.3.3 auf einem Mittwald Server.
Lösung: Ihr müsst in der php.ini (Pfad im Apache: /etc/php5/apache2/) die date.timezone auf Europe/Berlin setzen. Der Eintrag sieht dann so aus:
date.timezone = "Europe/Berlin"
Führt man das compare beim Database Analyser im TYPO3 Install Tool aus, könnten diese Zeilen erscheinen.
# ALTER TABLE cache_hash ENGINE=InnoDB;
Current value: ENGINE=MyISAM
# ALTER TABLE cachingframework_cache_hash ENGINE=InnoDB;
Current value: ENGINE=MyISAM
# ALTER TABLE cachingframework_cache_hash_tags ENGINE=InnoDB;
Current value: ENGINE=MyISAM
# ALTER TABLE cache_imagesizes ENGINE=InnoDB;
Current value: ENGINE=MyISAM
# ALTER TABLE sys_log ENGINE=InnoDB;
Current value: ENGINE=MyISAM
# ALTER TABLE cache_pages ENGINE=InnoDB;
Current value: ENGINE=MyISAM
# ALTER TABLE cache_pagesection ENGINE=InnoDB;
Current value: ENGINE=MyISAM
# ALTER TABLE cachingframework_cache_pages ENGINE=InnoDB;
Current value: ENGINE=MyISAM
[...]
Bleiben diese Zeilen auch nach einem „write to database“, dann liegt das Problem meist darin, dass die Datenbank tatsächlich die InnoDB nicht unterstützt. Dies kann man nochmal überprüfen, indem man sich in PhpMyAdmin einloggt und die genannten Tabellen man überprüft und schaut, ob im DropDown Feld unter Typ kein InnoDB vorhanden ist. Dies war z.B. bei einem kleineren WebPack unter hosteurope der Fall.
Das fehlende Update der Tabellen scheint aber keine Fehler hervorzurufen und kann somit ignoriert werden. Ich vermute, dass dies auch reine Performance Optimierung war.