Diese Seite enthält ein paar kleine Fixes für diverse Extensions. Ich habe jeweils die Versionen dazu geschrieben, da die Fixes zum Teil ewas älter sind.
Beim Zugriff auf die Tag-Blacklist kommt es bei wf_tagcloud_bl und ab_downloads ab Typo3 Version 4.6 zu PHP-Fehlern in der mod1/index.php:
[10-Mar-2013 17:28:54] PHP Fatal error: Call to undefined method t3lib_div::fixed_lgd_pre() in /var/www/htdocs/html/typo3conf/ext/wf_tagcloud_bl/mod1/index.php on line 130
bzw.
[13-Mar-2013 11:20:34] PHP Fatal error: Call to undefined method t3lib_div::fixed_lgd_pre() in /var/www/htdocs/html/typo3conf/ext/ab_downloads/mod1/index.php on line 183
Ursache ist, dass die Methode t3lib_div::fixed_lgd_pre in Typo3 Version 4.6 nicht mehr definiert ist.
Ersatz für diese Methode ist t3lib_div::fixed_lgd_cs, allerdings wird hier der zweite Parameter negiert, statt z.B. "50" muss dann also "-50" notiert werden.
Hier habe ich auch eine Diff abgelegt, mit der man die index.php für wf_tagcloud_bl patchen kann.
Das hier wäre die Diff für ab_downloads. In dieser ist auch gleich angepasst, dass es bigDoc::middle() und t3lib_div::GPvar() nicht mehr gibt. Das entspricht diesen Fehlermeldungen:
[13-Mar-2013 11:26:29] PHP Fatal error: Call to undefined method t3lib_div::GPvar() in /var/www/htdocs/html/typo3conf/ext/ab_downloads/mod1/index.php on line 238
und
[13-Mar-2013 11:29:27] PHP Fatal error: Call to undefined method bigDoc::middle() in /var/www/htdocs/html/typo3conf/ext/ab_downloads/mod1/index.php on line 222
Diese Information bezieht sich auf die Version 1.1.0 und 1.1.1 von wf_tagcloud_bl und die Version 1.9.6 von ab_downloads.
Beim Erstellen einer Sitemap aus Inhalten von tt_news und mm_forum kommt es bei tx_googlesitemap zu PHP-Fehlern in der class.tx_mcgooglesitemap_base.php:
Bei Zugriffen auf die Daten der News kommt es dabei zum Fehler:
[14-Aug-2008 18:07:55] PHP Warning: array_merge() [<a href='function.array-merge'>function.array-merge</a>]: Argument #2 is not an array in /<rest_of_path>/typo3conf/ext/mc_googlesitemap/class.tx_mcgooglesitemap_base.php on line 130
Bei Zugriffen auf die Daten der Foren kommt es dabei zum Fehler:
[14-Aug-2008 17:52:40] PHP Warning: array_merge() [<a href='function.array-merge'>function.array-merge</a>]: Argument #2 is not an array in /<rest_of_path>/typo3conf/ext/mc_googlesitemap/class.tx_mcgooglesitemap_base.php on line 103
Folge ist dann auch, dass in der Sitemap das Feld <changefreq> nicht gesetzt wird.
Ursache ist, dass $tema an dieser Stelle nicht definiert ist (und damit auch nicht als Array).
Das lässt sich einfach durch Einfügen einer Zeile in der Form:
if (!defined($tema)) {$tema=array();}
beseitigen.
Hier habe ich auch eine Diff abgelegt, mit der man diese Zeilen einfügen kann.
Diese Information bezieht sich auf die Version 0.4.2 von mc_googlesitemap.
Trotz korrekter Konfiguration kann es vorkommen, dass tx_ncstaticfilecache den Cache beim Zugriff über einen Browser neu aufbaut, obwohl kurz vorher ein Crawler-Durchlauf stattgefunden hat und die Seiten im Cache-Verzeichnis vorliegen.
Ursache ist ein kleiner Fehler in den .htaccess-Beispielen für die realurl-Variante (gzip.realurl.htaccess und plain.realurl.htaccess). Die jeweilige simulateStatic-Variante ist korrekt.
Der Fehler steckt in der Zeile
RewriteCond %{DOCUMENT_ROOT}/typo3temp/tx_ncstaticfilecache/%{HTTP_HOST}/%{REQUEST_URI}index.html%{ENV:TX_NCSTATICFILECACHE_GZIP} -f
bzw.
RewriteCond %{DOCUMENT_ROOT}/typo3temp/tx_ncstaticfilecache/%{HTTP_HOST}/%{REQUEST_URI}index.html -f
Hier gehört jeweils nach %{REQUEST_URI} ein Slash ("/"), so dass die Zeilen korrekt so aussehen:
RewriteCond %{DOCUMENT_ROOT}/typo3temp/tx_ncstaticfilecache/%{HTTP_HOST}/%{REQUEST_URI}/index.html%{ENV:TX_NCSTATICFILECACHE_GZIP} -f
bzw.
RewriteCond %{DOCUMENT_ROOT}/typo3temp/tx_ncstaticfilecache/%{HTTP_HOST}/%{REQUEST_URI}/index.html -f
pmkttnewstwitter dürfte der nützlichste Tweet-Generator sein, weil er direkt auf tt_news-Beiträge verweisen kann.
Leider kann die Original-Version, die im TER liegt, nicht mit dem seit September 2010 obligatorischen oauth von Twitter umgehen.
Es gibt zum Glück einen Patch dafür, und zwar unter http://forge.typo3.org/issues/9598.
Es existiert an dieser Stelle auch eine komplett umgepatchte Version, aber diese habe ich nicht benutzt, weil sie auch einige andere Sachen geändert hat, die ich nicht erst analysieren wollte (Folge ist, dass da z.B. CURLOPT_FOLLOWLOCATION auf 1 gesetzt wird, was bei nicht wenigen Typo3-Installationen zu Problemen führen dürfte, weil diese Option NICHT akzeptiert wird, wenn entweder im PHP safe_mode=on oder ein open_basedir gesetzt sind).
Mit dem Patch funktioniert pmkttnewstwitter problemlos, wenn man sich, wie in der Dokumentation zur Extension zw_twitterit (http://typo3.org/extensions/repository/view/zw_twitterit/current/) beschrieben, die Daten für
twitterconsumerkey
twitterconsumersecret
twitteraccesstoken
twitteraccesstokensecret
besorgt.
Abweichend von dieser Doku sowie den Informationen in den Patch-Kommentaren ist auch die Angabe von
twitterUser
twitterPassword
erforderlich, sonst funktioniert da nichts, denn dann wird das Script in der Extension einfach beendet.
Außerdem muss man darauf achten, dass die korrekte SinglePid für tt_news ermittelt werden kann. Hat man Artikel ohne Kategorie bzw. den Kategorien keine SinglePid zugewiesen und auch keine zentrale SinglePid definiert, dann wird anstelle der Short-URL ein "Error" an den Tweet angehangen.
Ein
plugin.tt_news.singlePid = <meine single Pid>
im Setup-Teil des Templates sorgt da für dauerhafte Abhilfe.
Die Dokumentation für die Erweiterung tagpack ist, vorsichtig formuliert, noch verbesserungswürdig. Dabei bietet sie sehr gute Möglichkeiten zur Erzeugung und Nutzung von Tagclouds unter Typo3.
Daher hier ein paar kleine Erkenntnisse zum Einsatz von tagpack.
Um Tags, die für tt_news-Records vergeben wurden, ausgeben zu können, sind folgende Einstellungen im TypoScript-Setup erforderlich:
plugin.tx_tagpack_pi1.userFunc.tagcloudElements.enabledRecords = tt_news
plugin {
tx_tagpack_pi3 = COA_INT
tx_tagpack_pi3 {
10 = USER
10 {
userFunc = tx_tagpack_pi3->main
taggedElements {
enabledRecords = tt_news,pages
contentLabel = Inhalte
recordLabels {
tt_news = Nachrichten
pages = Seiten
}
tt_news = COA
tt_news {
10 = TEXT
10.field = title
# Nachfolgend die Pid der Seite, die die tt_news-SINGLE-Ansicht enthaelt
10.typolink.parameter = 24
10.typolink.additionalParams=&tx_ttnews[tt_news]={field:uid}
10.typolink.additionalParams.insertData=1
10.wrap = <dt>|</dt>
20 = TEXT
20.field = short
20.wrap = <dd>|</dd>
}
}
}
}
}
In der realurl-Konfiguration habe ich benutzt:
'tag' => array(
array(
'GETvar' => 'tx_tagpack_pi1[uid]',
'lookUpTable' => array(
'table' => 'tx_tagpack_tags',
'id_field' => 'uid',
'alias_field' => 'name',
'addWhereClause' => ' AND NOT deleted',
'useUniqueCache' => 1,
'useUniqueCache_conf' => array(
'strtolower' => 1,
'spaceCharacter' => '-',
),
),
),
),
Google hat die Struktur für News-Sitemaps etwas modifiziert. Dadurch erstellt weeaargooglesitemap keine gültigen News-Sitemaps mehr, diese Sitemaps werden von Google zurückgewiesen.
Das lässt sich aber mit wenig Aufwand durch einen kleinen Patch fixen:
--- class.tx_weeaargooglesitemap_pi1.php.org 2011-01-06 13:37:40.000000000 +0100
+++ class.tx_weeaargooglesitemap_pi1.php 2011-01-06 14:17:19.000000000 +0100
@@ -306,18 +306,24 @@
$link = preg_replace("/<a href=\"(.*)\".*/", "\\1", $link);
$string = " <loc>{$link}</loc>\n";
- $string .= " <lastmod>".gmdate("Y-m-d\TH:i:s\Z", $row["tstamp"])."</lastmod>\n";
+# $string .= " <lastmod>".gmdate("Y-m-d\TH:i:s\Z", $row["tstamp"])."</lastmod>\n";
+ $string .= " <lastmod>".date('c', $row["tstamp"])."</lastmod>\n";
$string .= " <priority>0.5</priority>\n";
/* news sitemap */
if ($this->defaultCode == 'google')
{
$string .= " <news:news>\n";
- $string .= " <news:publication_date>".gmdate("Y-m-d\TH:i:s\Z", $row["tstamp"])."</news:publication_date>\n";
-
+ $string .= " <news:publication>\n";
+ $string .= " <news:name>" . htmlspecialchars($GLOBALS['TSFE']->tmpl->setup['sitetitle']) . "</news:name>\n";
+ $string .= " <news:language>" . htmlspecialchars($GLOBALS['TSFE']->lang) . "</news:language>\n";
+ $string .= " </news:publication>\n";
+ $string .= " <news:publication_date>" . date('c', $row["tstamp"]) . "</news:publication_date>\n";
+ $string .= " <news:title>" . htmlspecialchars($title) . "</news:title>\n";
+# $string .= " <news:publication_date>".gmdate("Y-m-d\TH:i:s\Z", $row["tstamp"])."</news:publication_date>\n";
if ($row['keywords'] != '')
{
- $string .= " <news:keywords>" . htmlspecialchars($row['keywords']) . "</news:keywords>\n";
+ $string .= " <news:keywords>" . htmlspecialchars($row['keywords']) . "</news:keywords>\n";
// <news:stock_tickers>MSFT, NYSE:HD</news:stock_tickers>
}
$string .= " </news:news>\n";
@@ -372,7 +378,8 @@
$string = "<url>\n";
$string.= " <loc>{$this->url}".$link."</loc>\n";
- $string.= " <lastmod>".gmdate("Y-m-d\TH:i:s\Z", $time)."</lastmod>\n";
+# $string.= " <lastmod>".gmdate("Y-m-d\TH:i:s\Z", $time)."</lastmod>\n";
+ $string .= " <lastmod>".date('c', $time)."</lastmod>\n";
$priority = ($this->data[$pages_row[ $id_name ]][1]?$this->data[$pages_row[ $id_name ]][1]:"0.5");
Hier auch zum Download
Dieses betrifft wt_spamshield 1.1.0, andere Versionen können ein anderes Verhalten zeigen!
Beim Einsatz von wt_spamshield kommt es beim Zugriff über Proxies, die mit clamav geschützt sind, (z.B. squid mit havp und clamav) zu Meldungen, dass der Webserver die Malware "HTML.CVE_2012_1526" verbreitet.
Das ist natürlich eine Fehlmeldung, wt_spamshield ist NICHT infiziert! Aber die Signatur, unter der clamav den ""HTML.CVE_2012_1526" findet, entspricht einer Zeichenkette, die wt_spamshield in die Webseite einbaut.
Konkret handelt es sich um ein zweimaliges Vorkommen eines -XXXem (X muss als "9" gelesen werden) im honeypot.
Abhilfe:
in den Constants des Templates dieses einfügen:
plugin.wt_spamshield.honeypot.css.inputStyle = style="position:absolute; margin:0 0 0 -9999px;"
und ins Setup dieses:
plugin.wt_spamshield.honeypot.explanation.wrap = <label class="wt_spamshield_label wt_spamshield_honey" style="position:absolute; margin:0 0 0 -9999px;">|</label>
Anmerkung: es genügt NICHT, die "em" stehen zu lassen und die drei Neunen mit einer vierten zu ergänzen - das führt dann nämlich zur Malware "HTML.CVE_2012_1526-3"!
Wird tx_ncstaticfilecache (Version 2.3.4) in Typo3 6.1 eingesetzt, so stolpert es darüber, dass es die Methoden t3lib_div::testInt und t3lib_div::int_from_ver nicht mehr gibt.
Abhilfe ist natürlich einfach, die beiden alten Methoden müssen einfach durch die neuen ersetzt werden:
--- class.tx_ncstaticfilecache.php.org 2010-12-30 17:35:55.000000000 +0100
+++ class.tx_ncstaticfilecache.php 2013-08-08 10:52:30.888813727 +0200
@@ -296,7 +296,7 @@
// Clear temp files, not frontend cache.
break;
default:
- if (t3lib_div::testInt($cacheCmd)) {
+ if (t3lib_utility_Math::canBeInterpretedAsInteger($cacheCmd)) {
$this->debug('clearing cache for pid: ' . $cacheCmd);
$this->deleteStaticCache($cacheCmd);
} else {
@@ -392,7 +392,7 @@
}
// Workspaces have been introduced with TYPO3 4.0.0:
- $workspacePreview = (t3lib_div::int_from_ver(TYPO3_version) >= 4000000 && $pObj->doWorkspacePreview());
+ $workspacePreview = (t3lib_utility_VersionNumber::convertVersionNumberToInteger(TYPO3_version) >= 4000000 && $pObj->doWorkspacePreview());
$file = $uri . '/index.html';
$file = preg_replace('#//#', '/', $file);
Hier wäre der Patch dafür zum Herunterladen
tx_crawlerlib (3.5.0) kommt mit den neuen Versionen von realurl (1.12.6) nicht klar, weil die realurl-Methoden setConfig und encodeSpURL_doEncode mittlerweile protected sind. Resultat ist natürlich, dass der Crawler nicht mehr läuft, sondern diese Fehlermeldungen liefert:
PHP Fatal error: Call to protected method tx_realurl::setConfig() from context 'tx_crawler_lib'.....
PHP Fatal error: Call to protected method tx_realurl::encodeSpURL_doEncode() from context 'tx_crawler_lib'.....
Abhilfe wäre dieser Patch
--- class.tx_crawler_lib.php.org 2013-08-09 06:48:00.000000000 +0200
+++ class.tx_crawler_lib.php 2013-05-05 20:16:53.000000000 +0200
@@ -271,7 +271,7 @@
require_once(t3lib_extMgm::extPath('realurl') . 'class.tx_realurl.php');
/* @var $urlObj tx_realurl */
$urlObj = t3lib_div::makeInstance('tx_realurl');
- $urlObj->setConfig();
+# $urlObj->setConfig();
if (!empty($vv['subCfg']['baseUrl'])) {
$urlParts = parse_url($vv['subCfg']['baseUrl']);
@@ -332,8 +332,16 @@
// realurl support (thanks to Ingo Renner)
$urlQuery = 'index.php' . $urlQuery;
if (t3lib_extMgm::isLoaded('realurl') && $vv['subCfg']['realurl']) {
- $uParts = parse_url($urlQuery);
- $urlQuery = $urlObj->encodeSpURL_doEncode($uParts['query'], $vv['subCfg']['cHash'], $urlQuery);
+# $uParts = parse_url($urlQuery);
+# $urlQuery = $urlObj->encodeSpURL_doEncode($uParts['query'], $vv['subCfg']['cHash'], $urlQuery);
+ $params = array(
+ 'LD' => array(
+ 'totalURL' => $urlQuery
+ ),
+ 'TCEmainHook' => true
+ );
+ $urlObj->encodeSpURL($params);
+ $urlQuery = $params['LD']['totalURL'];
}
// Scheduled time:
Der Patch wäre auch hier zum Herunterladen
|
