20.November 2017    

Google

   homeProjekteSoftwareTypo3-Fixes

 

Hobby 234x60
reichelt elektronik – Elektronik und PC-Technik
Seite zuletzt geändert: 09.08.2013 07:22

Typo3-Fixes

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.

PHP-Fehler in mod1/index.php bei wf_tagcloud_bl und ab_downloads

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.

 

PHP-Fehler in class.tx_mcgooglesitemap_base.php bei News und Forum

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.

 

tx_ncstaticfilecache baut Cache immer wieder neu auf

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

 

pnkttnewstwitter mit oauth

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.

 

tagpack mit tt_news und realurl

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-Kompatibilität von weeaargooglesitemap

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

 

wt_spamshield-Daten werden von clamav als "HTML.CVE_2012_1526" erkannt

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"!

tx_ncstaticfilecache: Fehler bei Typo3 6.1

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_crawler: Call to protected method tx_realurl::setConfig()

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

Keine Kommentare
Kommentar hinzufügen

* - Pflichtfeld

*



*
Copyright © 2008-2017