htmlentities() ist ja eine Recht nette PHP Funktion um schnell das ganzen HTML aus einem String zu bekommen, weil man den z.B. (als Code) ausgeben möchte. Aber: Die Funktion macht UTF-8 kaputt! Also muss man entweder sowas wie utf8_decode(htmlentities($str)) machen, oder man schaut sich die Argumente noch mal genau an, und stellt fest, dass man das Charset auf explizit angeben kann. Diese Variante lässt UTF-8 am Leben:
htmlentities($str, ENT_COMPAT | ENT_HTML401, "UTF-8");
Wer möchte das nicht?
Und schon wieder läuft dieser Blog auf einem neuen Server!
Zuletzt war ich ja etwas holperig von meinem alten Hoster zu netcup gewechselt, dort lief der Blog zusammen mit ziemlich viel anderem Kram auf einem sehr schwachen (200 RAM + 400 MB Swap) vServer. Das war super zu rumspielen, und hat meine Linux-Kenntnisse sicher verbessert, aber auf die Dauer war das nichts. Also war mit dem Ende der Vertragslaufzeit mal wieder ein Wechsel fällig. Das Verfahren war etwas einfacher, da ich bei netcup geblieben bin (und sehr zufrieden bin :))
Also wieder das gleiche Prinzip wie immer: Hosting-Paket parallel buchen, Daten rüber schieben, DNS umstellen, fertig. Im Grunde lief auch alle glatt, von ein paar Blödheiten meinerseits mal abgesehen (bei denen der Support schnell helfen konnte, wie immer eine 
Spitzen-Antwortzeit). Letztes Mal hatte ich einfach nur die MySQL Daten exportiert und wieder importiert, und die PHP-Dateien kopiert, die Mal wollte ich es etwas anders machen: Meine WordPress Installation war schon ziemlich alt, und in der Datenbank lagen noch viele Einträge von alten Plugins rum, daher wollte ich mal wieder neu anfangen. Die Inhalte sollten aber natürlich mitkommen… Das ganze stellte sich als ziemlich einfach heraus: Im alten Blog die Daten exportiert, im neuen wieder importiert (s. Screenshot) und schon war alles wieder da. Der Importer (ist ein Plugin), hat auch versucht, die ganzen Bilder vom alten Server herunterzuladen, aber leider nicht einzeln sondern in einem Aufruf alles, was natürlich nach ein paar Bildern abgebrochen wurde. Es hat allerdings ausgereicht, einfach den wp-content Ordner per FTP zu kopieren. Das funktioniert wirklich gut, und ich habe wieder eine frische Datenbank ohne Altlasten (von ein paar Beiträgen mal abgesehen, die ich lieber vergessen würde… :)).
Für die Uni muss ich ja nun viel C schreiben, und da gibt es ja nun mal diese wunderbaren Pointer. Sollte man davon mal eine falsch setzen bricht das Programm ab, und es gibt eine wunderbare Fehlermeldung: Segementation Fault: 11. Jetzt heißt es also, den Fehler mit jede Menge printf() eingrenzen und nach sehr viel Suchen dann evtl. auch finden.
Nach den ich heute mal wieder einen Pointer falsch hatte, habe ich mal nachgesehen, ob es nicht auch einfacher geht… Geht es natürlich… Also eine kleine Anleitung! Ich habe extra für euch ein Programm mit Fehler gebaut: Sowas würde mir sonst natürlich nie passieren 😉
Was nun? Als ersten müssen wir dem Betriebsystem sagen, dass es einen Speicherdump (coredump) erstellen soll, wenn ein Programm abstürzt. Die Dinger werden ziemlich groß, deswegen ist das normalerweise ausgeschaltet. Um es für die akutelle Shell zu aktivieren geben wir ulimit -c unlimited ein. Damit wird bei nächsten Absturz ein core-dump erstellt. Damit kommen wir schon recht weit, doch wir können das Programm noch im Debug-Modus kompilieren, damit wir noch besser sehen, was da schief gelaufen ist. Dazu einfach gcc den Parameter -g mitgeben (ja, clang kann das auch). Danach lassen wir das Programm wieder abstürzen:
Na, aufgepasst? Da steht jetzt (core dumped). Nun schauen wir mal in den Ordner /cores, dort liegt unser core dump! Und er ist (für dieses einfache Programm) >300 MB groß! Das war das, was ich oben meinte…