CategoryBugs | Vulnerabilities

TYPO3 6.1.5 Extension Installation schlägt fehl

Ursprünglich vermutete ich, das es an der RealURL-Extension liegt und diese doch nicht mit dem TYPO3 CMS 6.1.5 kompatibel ist. Nach einem Vergleich mit einem Mittwald-Host, mit gleicher TYPO3- und RealURL-Extension-Version, war klar, es muss an der Server Konfiguration liegen. Im Internet gibt es bereits einen weiteren Post (http://typo3.3.n7.nabble.com/TYPO3-6-1-5-Keine-Extension-Installation-moglich-td249715.html) welcher über das selbe Phänomen berichtet. Die Änderung der Schreibrechte an der LocalConfiguration.php hat nichts bewirkt. Im Gegensatz zu früheren TYPO3 CMS Versionen (< 6.0), wird die Datei immer neu erstellt, da nach einem erneuten Installationsversucht im Extension Manager, die Schreibrechte wieder auf den ursprünglichen Wert gesetzt sind. Um Inkompatibilitäten mit der Extension auszuschließen versuchte ich die Recycler-Extension zu installieren. [caption id="attachment_1216" align="aligncenter" width="300"]typo3-recycler extension Manager typo3-recycler extension Manager[/caption]

Wie in der Abbildung links unten in der Ecke zu sehen, ist der Recycler installiert, im Extension Manager wird aber weiterhin der graue Baustein angezeigt, statt der grüne. Erst das manuelle Hinzufügen, von “recycler” in die LocalConfiguration.php brachte das gewünschte Ergebnis. Danach unbedingt den Inhalt von typo3temp leeren, da es ansonsten zu unerwarteten Ergebnissen kommen kann.

Die Deinstallation der Extension über den Extension Manager funktioniert.

[random_content group_id=”211″ num_posts=”1″]

Notice: wpdb::escape ist seit Version 3.6 veraltet!

Bei der Aktualisierung einer WordPress Installation von 3.5 auf 3.6 erschien folgende Meldung mehrfach auf dem Dashboard


Notice: wpdb::escape is deprecated since version 3.6! Use wpdb::prepare() or esc_sql() instead. in /var/www/web4/html/wordpress/wp-includes/functions.php on line 2871 Notice: wpdb::escape ist seit Version 3.6 veraltet! Benutze stattdessen wpdb::prepare() or esc_sql(). in /var/www/project/wordpress/wp-includes/functions.php on line 2871

In Zeile 2781 der Datei “functions.php” steht jedoch die Funktion, welche die Meldung ausgibt. Von dem escape-Aufruf ist weit und breit keine Spur. Mittels grep habe ich dann nach allem was ” escape(” beinhaltet gesucht und manuell ersetzt.


grep -r ' escape(' ./

Die Herausforderung ist, das als Ersatz für wpdb::escape zwei Funktionen genannt werden. Welche davon jetzt die Richtige ist, habe ich abhängig davon gemacht, ob die Eingabe nur ausgegeben werden sollte, dann wpdb::prepare, oder in die Datenbank gespeichert werden soll, dann esc_sql.

Nachdem ich alle Dateien “behandelt” hatte, mit der Dateiendung php, erschien weiterhin die Meldung auf dem Dashboard. Erst das Auskommentieren der gesamten “escape”-Funktion brachte eine neue Erkenntnis:


Warning: array_map() expects parameter 1 to be a valid callback, class 'wpdb' does not have a method 'escape' in /var/www/project/wordpress/wp-content/plugins/broken-link-checker/includes/link-query.php on line 295
Warning: implode(): Invalid arguments passed in /var/www/project/wordpress/wp-content/plugins/broken-link-checker/includes/link-query.php on line 300

Der eigentliche Übeltäter scheint somit die Erweiterung “Broker link Checker” zu sein. Nachdem diese deaktiviert wurde, verschwand die Meldung. Die angepassten Dateien habe ich unverändert gelassen.

Bei meinem grep wurde die Datei “link-query.php” nicht aufgeführt, da “escape” per array_map aufgerufen wurde:


$s_parser_type = array_map(array(&$wpdb, 'escape'), $s_parser_type);

Google Webmaster vs. Yandex Webmaster

Im August 2012 schrieb ich hier im Blog das erste Mal, über die EMails von Google bzgl. der Nicht-Erreichbarkeit des Blogs. Es folgten weitere Einträge, ohne das sich an der Erreichbarkeit etwas geändert hat. Selbst der Server wurde gewechselt, jedoch ohne eine Verbesserung.

Bei der Analyse der Apache Access-Logfiles sah ich, das auch die Suchmaschinen Bing, von Microsoft, und Yandex, aus Russland, meine Seite crawlten. Ich fragte mich, ob diese die selben Probleme haben wie der Googlebot und ob sie auch eine Webmaster Zentrale anbieten. Über Google fand ich die entsprechende Toolbox von Bing (http://www.bing.com/toolbox/webmaster) bzw. von Yandex (http://webmaster.yandex.ru/). Ich registrierte ein Konto und implementierte den entsprechenden Verifikations-Code in meinen Meta-Angaben.

Während Bing nichts auffälliges anzeigte, gab es bei Yandex gleich in zwei Fehler-Kategorien eine Häufung. Aufgrund der automatischen Übersetzung durch Google Translate kann der Fehlercode ggf. abweichen.

Ungültige Dokument Format

Ungültige Dokument Format

Mit der falschen Anzahl von Daten

Mit der falschen Anzahl von Daten

Auffällig ist die Auflistung von nur PDF-Dateien. Also probierte ich es selbst einmal aus. Tatsächlich, irgendwas scheint mit der PDF Erweiterung nicht mehr zu funktionieren. Der Chrome-PDF-Viewer zeigt, dass das PDF vollständig geladen wäre, gleichzeitig dreht sich der Spinner im Tab. Wenn dieser nach einiger Zeit aufgehört hat sich zu drehen, ist kein PDF zu sehen.

Rückblickend kann ich mich auch nicht erinnern, wann es für die PDF Erweiterung das letzte Mal ein Update gegeben hat. Daher habe ich es jetzt mal deaktiviert und warte gespannt auf den nächsten Besuch vom Googlebot.

The requested URL is too large to process.

Eine interessante Meldung, vor allem weil es dem Chrome Browser handelt und bei der Webseite die Google Webmaster Sitemap, bei dem Versuch meine Nachrichten bzgl. den Crawling-Fehlern, zu löschen. Lustig auch das Title Tag “Error 414 (Request-URI Too Large)!!1” fehlt nur noch das hinten “elf” steht. Nach einer Überprüfung (www.zeichenzähler.de) stellte sich heraus das die URL tatsächlich 3130 Zeichen enthält. In einer Antwort auf Stack Overflow (http://stackoverflow.com/questions/6955302/http-error-414-the-request-url-is-too-long) wird die praktikable Länge mit 2000 Zeichen angegeben.

Der Wikipedia Artikel Query String (http://en.wikipedia.org/wiki/Query_string) benennt explizit den Internet Explorer und das dieser nur maximal 2083 Zeichen in der URL versteht. Ich bin mir nicht sicher, warum die URL in meinem Fall so lang ist bzw. die Daten nicht mit POST übertragen werden. Trotz der Fehlermeldung wurden meine Nachrichten gelöscht, was ich jetzt unbedingt erwartet hätte.

Google Webmaster Sitemap: Gekürzte Antwort Teil 2

Wie angekündigt, habe ich meine Seite nochmals mit wGet gespidert, zunächst nach der selben Methode wie im Artikel “Googlebot can’t access your site” beschrieben. Um das Logfile zu minimieren habe ich zusätzlich die Option -A html hinzugefügt, damit nur html Dateien und keine Bilder, JavaScript und Anderes herunterladen geladen wird. Im Logfile konnte ich keine Auffälligkeiten entdecken.

Als nächstes schrieb ich zwei kurze PHP-Skripte:

[PHP]
// file: start.php

$link = mysql_connect(DB_HOST, DB_NAME, DB_PASSWORD);
if (!$link) {
die(‘Could not connect: ‘ . mysql_error());
}

$db_selected = mysql_select_db(DB_NAME, $link);

mysql_query(“INSERT into statistik (ip, token, time1, script)
VALUES (‘”.$_SERVER[‘REMOTE_ADDR’].”‘, ‘”.$_SERVER[‘REQUEST_TIME’].”‘,'”.microtime().”‘,'”.mysql_real_escape_string($_SERVER[‘REQUEST_URI’]).”‘ );”);

mysql_close($link);
[/PHP]

und passend dazu auch

[PHP]
// file: stop.php

$link = mysql_connect(DB_HOST, DB_NAME, DB_PASSWORD);
if (!$link) {
die(‘Could not connect: ‘ . mysql_error());
}

$db_selected = mysql_select_db(DB_NAME, $link);

$str = “UPDATE statistik SET time2 = ‘”.microtime().”‘
WHERE ip = ‘”.$_SERVER[‘REMOTE_ADDR’].”‘ AND token = ‘”.$_SERVER[‘REQUEST_TIME’].”‘ AND script = ‘”.mysql_real_escape_string($_SERVER[‘REQUEST_URI’]).”‘;”;

mysql_query($str);

mysql_close($link);
[/PHP]

diese wurden direkt in die index.php eingebunden:

[PHP]
// file: index.php

define(‘WP_USE_THEMES’, true);

require(‘./start.php’);

/** Loads the WordPress Environment and Template */
require(‘./wp-blog-header.php’);

require_once(‘./stop.php’);
[/PHP]

Zunächst vermutete ich, das es am Favicon.ico liegen könnte

[PHP]
IP Token time1 time2 Script
6.23.4.8 1352762248 0.29693200 1352762248 0.43673200 1352762248 /5/google-webmaster-sitemap-gekurzte-antwort/2012/11/11/
6.23.4.8 1352762251 0.13867900 1352762251 /favicon.ico
6.23.4.8 1352762330 0.97333000 1352762330 0.10298000 1352762331 /5/google-webmaster-sitemap-gekurzte-antwort/2012/11/11/
6.23.4.8 1352762337 0.54685600 1352762337 /favicon.ico
[/PHP]

Also bastelte ich eines, es kam aber weiterhin zu Datenbank-Einträgen bei denen keine “time2” angegeben war.

Erst nach dem ich den WordPress Quick Cache abgeschaltet hatte, wurde auch immer eine time2 eingetragen. Mal schauen was Google bzw. Webmaster Sitemap Tools beim nächsten Crawlen sagen.

© 2020 BugBlog.de

Theme by Anders NorénUp ↑