CategoryBugs | Vulnerabilities

SSD Festplatte wird nicht mehr erkannt – Crash!

Ohne jede Vorwarnung oder irgend ein Anzeichen wird meine SSD Vertex 2 nicht mehr in meinem Notebook erkannt. Ich muss zugeben, dass mir das Risiko bekannt war und nach über 4 Jahren in Benutzung und immer treuen Diensten kann ich der Festplatte auch keinen Vorwurf machen. Da ich im Keller noch die Original-Festplatte liegen hatte, welche sich ohne Probleme starten ließ und auf der auch noch das ursprüngliche Betriebssystem, ein Windows 7 Home, installiert ist, ging der Umstieg / Austausch relativ schnell. Wobei schnell relativ ist, denn man merkt schon bzw. hat das Gefühl, dass die Festplatte mit ihren 5.400 Umdrehungen deutlich langsamer reagiert als die SSD. Die Installation von Updates hat gefühlt 3 Tage gedauert, weil ich auch immer nur morgens und abends auf den Update-Button klicken konnte. Andererseits muss ich mir um den Speicherplatz erstmal keine Sorge mehr machen, denn mit 285 GB habe ich 2,5 mal so viel wie bei der SSD. Ausgehend von diesem Post bzw. dem Ereignis habe ich mir eine Reihe von Gedanken gemacht wie grundsätzlich mit Daten umzugehen ist. Wenn ich die Zeit finde, werde ich es hier im Blog entsprechend protokollieren.

Tipp für den nächsten Festplatten Crash: Bei der Installation kein Windows Passwort setzen, denn die ganzen Updates brauchen immer wieder einen Neustart und wenn sich keiner anmeldet, glaube ich, sucht der PC nicht nach weiteren Updates. Daher zur Beschleunigung des Update-Prozesses erstmal auf ein Passwort verzichten, welches später man immer noch setzen kann.

Call to undefined method GeneralUtility::readLLXMLfile()

Eine Aktualisierung von der TYPO3 CMS Version 4.5 LTS auf die 6.2 LTS wird wahrscheinlich die Tage häufiger durchgeführt, da es sich um die LTS-Versionen handelt und bei der 4.5 der Support ausläuft. Besonders wenn viele Extensions installiert sind, kann der Umstieg mehr als holprig werden. In diesem Fall kam es im Backend zu einer Fehlermeldung, wenn man neue Inhalte anlegen wollte:

Fatal error: GeneralUtility::readLLXMLfile

Folgende Fehlermeldung wird angezeigt, wenn auch ggf. in einer anderen Datei:

Fatal error: Call to undefined method TYPO3\CMS\Core\Utility\GeneralUtility::readLLXMLfile() in class.tx_xyz_wizicon.php on line 65

Glück im Unglück, die Fehlermeldung ist sehr sprechend und es ist auch gleich der Dateiname und die Zeilennummer angegeben, wodurch die Behebung schnell durchgeführt werden kann.

Der Fix: makeInstance(‘t3lib_l10n_parser_Llxml’)

Einfach in die angezeigte Datei wechseln und mittels Strg+F die entsprechende Stelle suchen und folgende Ersetzung durchführen:

// $LOCAL_LANG = t3lib_div::readLLXMLfile($llFile, $GLOBALS['LANG']->lang);
$parser = t3lib_div::makeInstance('t3lib_l10n_parser_Llxml');
$LOCAL_LANG = $parser->getParsedData($llFile, $GLOBALS['LANG']->lang);

Anschließend den Cache leeren und erneut Testen, ggf. kommt in einer Datei der Aufruf mehrmals vor, bzw. in vielen unterschiedlichen Dateien.

Gefunden hier: http://forge.typo3.org/issues/44413

Eine weitere Problematik ist häufig die Depraction-Meldung bzgl. Split().

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

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.

© 2021 BugBlog.de

Theme by Anders NorénUp ↑