Da ich momentan wieder ein bisschen mit meinem HTC Desire rumbastel und ein neues ROM aufspiele, entstehen dabei auch wieder ein paar neue Android Artikel. Wie etwa dieser hier.

Wenn ihr Probleme habt, einen Treiber für euer HTC Desire zu finden, etwa weil ihr (so wie ich) Screenshots machen wollt, mit dem Android SDK rumspielen wollt oder auch nur das Internet freigeben wollt, dafür aber nicht HTCs schrottige Software installieren wollt, habe ich einen genial einfachen Tipp für euch:

1. Ladet euch von die Synch Software für euer Gerät von HTCs Website runter. Für mein Desire wäre diese HIER zu finden.
2. Startet die Installation. Siehe da, noch vor der Installation der eigentlichen Software kommt dieses Fenster.
   
3. Lasst das Setup die entsprechenden Dateien installieren, brecht dann - vor der "richtigen" Installation - das Setup ab.

Schon habt ihr die HTC USB-Treiber ohne den lästigen Rattenschwanz.

Vor einer Woche beschrieb ich anläßlich des Erscheinens von Wordpress 3.3 wie man ein richtiges Wordpressbackup macht. Im Zuge des natürlich folgenden Blogposts der Wiederherstellung dieses Backups bin ich auf ein Problem gestoßen, dessen Lösung ich euch nicht vorenthalten will.

Will man über PHPMyAdmin eine Datenbank importieren, etwa um seinen Blog über XAMPP lokal laufen zu lassen, kann es schnell passieren, dass man durch diesen Fehler aufgehalten wird:

Bzw. schon vorher durch die Maximale Dateigröße in seinem Tatendrang gebremst wird:

8 Megabyte sind nicht viel, eine Datenbank wird schnell um einiges größer. Wie ändert man diese Größe also?

Da diese Limitierung nicht von PHPMyAdmin kommt, sondern von PHP selbst, müssen wir die php.ini editieren. Wir suchen die Einträge

upload_max_filesize

und

post_max_size

und setzen sie auf unseren Wunschwert. Hierbei sei gewarnt, dass diese Modifikation je nach Serverkonfiguration auch für andere User gilt. Habt ihr also noch mehr Benutzer auf eurem Server, seid vorsichtig mit dieser Einstellung. Da meine XAMPP-Umgebung nur für meine Tests genutzt wird, habe ich die Größe auf übertriebene 512M geschraubt, um nie mehr Probleme damit zu haben.

Startet nach den Änderungen euren Apache-Dienst neu und ihr solltet diesbezüglich nicht mehr gestört werden.

Eventuell wollt ihr für weitere Tests auch noch den Wert für die maximale Ausführungszeit von Skripten etwas hochsetzen. Sucht dazu den Wert

max_execution_time

in der php.ini und ändert ihn euren Anforderungen entsprechend.

Ich hatte in den letzten Monaten Probleme mit meinem RSS-Feed. Wie ich diese behoben habe, habe ich dort beschrieben. Dies hing vermutlich direkt mit meinem zweiten Problem zusammen, welches ich seit geraumer Zeit mit einem Plugin umgehe. Leider ist es bei mir nämlich so, dass Posts, deren Veröffentlichungszeitpunkt ich mit Wordpress' unheimlich praktischer Schedule-Funktion festlege, einfach nicht veröffentlicht werden. Hängt wahrscheinlich mit meinem supergünstigem Hosting bei tophoster.de zusammen, damals war ich eben geizig. Um das zu beheben, nutze ich nahezu seit Anbeginn dieses Blogs das Plugin WP Missed Schedule, welches intervallmäßig alle verpassten Posts dann nachträglich veröffentlicht.

Bevor ich mich für diese Variante entschieden habe, habe ich allerdings noch ein paar andere probiert, die ich euch nicht vorenthalten will:

Die Hosts-Datei manipulieren

Diesen Vorschlag habe ich über das englischsprachige Wordpress-Forum gefunden der die Fehlerlösung im Zusammenhang mit der Serververwaltung Plesk brachte. Da ich nur Webspace und keinen Server nutze, wollte ich gar nicht erst testen, ob ich ein SSH hinbekomme. Außerdem war mir die Lösung zu abwegig. Aber eventuell hilft sie ja einem von euch weiter. Die Blogeinträge diesbezüglich (beide in englisch) findet ihr HIER und HIER.

crontab.php editieren

Ist eine absurde Idee, die ich auch in den Weiten des Netzes gefunden habe. Die crontab.php ist die Datei, die für das Scheduling der Blogposts verantwortlich ist. Öffnet man sie mal und schaut sie sich an, fällt auf, dass die Datei unvollständig ist. Die letzen paar Zeilen sehen so aus:

			wp_unschedule_event($timestamp, $hook, $v['args']);

 			do_action_ref_array($hook, $v['args']);
		}
	}
}

die();

Da dies aber eine PHP-Datei ist und sie auch mit einem PHP-Tag begonnen wird, muss man sie auch mit dem entsprechenden Pendant beenden. Also solltet ihr ganz am Ende noch eine Zeile mit dem PHP-Endtag hinzufügen:

			wp_unschedule_event($timestamp, $hook, $v['args']);

 			do_action_ref_array($hook, $v['args']);
		}
	}
}

die();
?>

Wie gesagt habe ich mich für das Plugin entschieden. Wenn ich mir dann eventuell in Bälde einen vServer besorge und den Blog darauf umziehe, dann ändere ich daran vermutlich was, wenn der Fehler dann überhaupt noch existent ist.

Kleiner Tipp gegen den Schreck:

Wenn es euch wie mir passiert, dass ihr das ESXi-Testsystem über den vSphere Client in den Maintenance Mode packen wollt, aber versehentlich den Produktivserver erwischt und dieser euch meldet, dass er das machen wird, sobald alle VMs heruntergefahren sind (so fiel mir überhaupt auf, dass ich mich auf dem Produktivsystem befinde) könnt ihr das ganze Prozedere unten im Recent Tasks-Fenster mit einem Rechtsklick auf die entsprechende Aktion wieder abbrechen und müsst nicht befürchten, dass euer Produktivsystem beeinträchtigt wird.

Ist sehr einfach, aber wenn man den Schreck in den Knochen hat und danach googlet, fand man bisher nichts.

Jeder Windows 7 User dürfte dieses Bild kennen:

Und wahrscheinlich dürften es auch fast alle Benutzer hassen. Erstens sucht Windows ungefragt, was sicherlich nicht jedem gefallen dürfte, und zweitens bringt dies meist absolut gar nichts abgesehen von einem zusätzlichen Klick auf Cancel. Wie also deaktiviert man dieses überflüssige Feature?

1. Das Windows Action Center (oder wie es auf deutsch heißt) öffnen. Geht entweder über die kleine Fahne im Systray oder über die Eingabe der ersten paar Buchstaben in der Quickbar der Startleiste.
   
2. Unter Change Action Center Settings habt ihr nun die Qual der Wahl, welche (in meinen Augen) überflüssigen Features ihr deaktivieren wollt. Ich habe auf dem Bild mal alle Punkte markiert, die ich für sinnvoll halte. So solltet ihr aus Datenschutzgründen das Customer Experience Improvement Program deaktivieren. Wenn euch die Lösungssuche nervt, solltet ihr wahrscheinlich auch direkt die Windows Backup und die Windows Troubleshooting Nachrichten deaktivieren.
   
3. Unter Problem reporting settings findet ihr unseren eigentlichen Stein des Anstoßes. Wenn ihr die Option auf Never packt, werdet ihr auch nie wieder davon genervt werden. Als Administrator könnt ihr die Option auch direkt für alle User deaktivieren. Das sähe dann etwa so aus: