Ich bin nun wirklich kein Freund von Internet-Foren. Egal in welchem Forum ich mich bewege, gibt es immer Objekte die Ihr kleines Ego versuchen aufzupolieren und sich wahlweise mit rummoppern oder mit überheblichen Rechthaben in den Vordergrund drängeln. Das eigentliche Problem des Fragestellenden wird da vollkommen in den Hintergrund geschoben. ICH LIEBE ANTWORTEN WIE:

Lese dir mal die FAQ durch (ca 200 Seiten)

Die Antwort steht schon irgendwo im Internet, suche in Google

Sucht man in Google kommt man auf lauter Beiträge wo die beiden obigen Antworten stehen oder der frage stellende Antwortet das der Fehler behoben wurde, teilt aber nicht mit wie.

Oooooder aber irgendwer sagt, das man sowieso alle falsch macht und das gaaaanz anders machen soll. Wahlweise wird empfohlen auf Mac / Linux bzw. Android oder iOS umzusteigen…

Ähhhh ja.

Und so ist es auch mir ergangen als ich neulich beim Programmieren lernen auf einen Fehler gestossen bin den ich einfach nicht lösen konnte. Letztendlich war es wirklich nur ein doofer Denkfehler…. na wie gut das ich bloggen kann. Hoffe es hilft dem nächsten.

Ich schrub folgende Schleife in PHP

echo ”<p>Folgende Strichlisten sind bereits vorhanden</p><u>”;

$res = mysql_query (‘select * from strichzettel’);
$num = mysql_num_fields($res);
for ($i=1; $i<=$num; $i++)
{
echo mysql_field_name($res, $i);
}
?>

und erhielt dann beim Aufruf der Schleife die Meldung

Warning: mysql_field_name() [function.mysql-field-name]: Field 2 is invalid for MySQL result index 7 in C:\xampp\htdocs\strich\install.php on line 165

Der Fehler ist eigentlich recht einfach. Wird der in der for Schleife eingestellt Vergleichparameter ($i=$num) erreicht, läuft die Schleife noch einmal durch. Will Echo dann den Feldnamen mit dem Wert $i ausgeben, geht das nicht weil das Feld nicht vorhanden ist. Das wiederum liegt daran das die Zählung der Spalten bei 0 anfangen (4 Spalten haben die Nummerierung 0,1,2,3 …). Die Lösung ist denkbar einfach…. das “=” im Vergleichsparameter muss weg.

Ich nutze und verlasse mich schon seit längerem auf das WordPress Plugin backupwp um ein vollständige Sicherung meines Blogs vorzunehmen. Das hat soweit auch immer sehr gut funktioniert, so gut das man schon gar nicht mehr drauf geachtet hat. Jetzt ist mir aber aufgefallen das ich bereits seit Mai keinerlei Backups mehr bekommen habe. Ich machte mich also auf die Fehlersuche und musste feststellen das mein Backup unkrompimiert bereits 90 MB groß ist und das alles funktioniert bis zum ZIPen des ganzen Backups….

Ich bin also davon ausgegangen das 90 MB wären einfach zuviel… dürfte zwar nicht sein aber was soll. Also mal die Tabellen von Piwik aus der Datenbanksicherung entfernt. Siehe da, nur noch knapp 50 MB und das packen funktioniert. Jetzt bricht aber der Mailversand ab, mit der Meldung das ein Speicherlimit überschritten worden sei.

So recht erklären kann ich mir das nicht. 256 MB memory_limit sollten eigentlich ausreichen. Egal, der Workaround mit dem ich es jetzt hinbekommen ist, das ich mir die Datenbank wöchtenlich per Mail senden lasse und die Dateien vom FTP Server in meine DropBox schiebe….. funktioniert.

Wer, so wie ich, gerne Artikel auf Vorrat schreibt, hat die Möglichkeit in Word Press einen Termin zur Veröffentlichung festzulegen. So kann man dem Besucher “vorgaukeln” das man seine Seite stets aktuell hält, obwohl man wochenlang nicht mehr online war ;o). Das ist aber nicht der Grund das zu machen. Ich persönlich hab manchmal kreative Phasen und kann schreiben und schreiben und schreiben. Und dann wieder hat man wochenlang keine Lust. Da macht es doch Sinne die Ergüsse häppchenweise zu liefern.

Aber zurück zum Thema. Manchmal kommt es aber vor, das diese Veröffentlichen nicht klappt. Dann erscheint hinter dem Artikel die Meldung “fehlende Planung” und der Artikel wurde nicht veröffentlicht. Ärgerlich ist das, gerade dann wenn man ebend lange Zeit nicht online ist. Also ich die 3rd Edition gestartet habe, hatte ich den Fehler relativ häufig und dann seit längerer Zeit nicht mehr. Sucht man in den Foren und allgemein im Netz nach der Meldung, erscheint immer der Hinweis auf eine recht alte WordPress Version und das der Fehler aber mit aktuellen WordPress Versionen nicht mehr auftritt. Komisch das ich Ihn aber hatte.

Neulich hatte ich Ihn aber wieder, nämlich als ich mit .access rum gespielt habe und die HP einige Stunden nicht erreichbar war. Und das bracht mich auf die Lösung des Problems:

Von dem Programmierer meines Backup-Plugins Daniel Hüsken hab ich erfahren wie die Cronjob Funktion in WordPress umgesetzt ist, ich zitiere:

Bei jedem Seitenaufruf einer Seite rufen die über curl oder ähnlich die seite wp-cron.php auf und kappen die Browser Verbindung. Sodas wp-cron ohne Browser Verbindung weiter läuft. Das PHP Zauberwort heißt hier ingnore_user_abort(). in der wp-cron wir dann über einen timestamp geprüft welcher Job ausgeführt werden muss.

Das heißt also, wenn keine Besucher kommen, kann auch der “Cronjob” nicht ausgeführt werden. Da die automatisierte Veröffentlichung sicherlich auch über diese Funktion gesteuert wird, erklärt das die Fehlermeldung. Erscheint “Fehlende Planung” im Backend, ist im Zeitraum x um den geplanten Termin kein Besucher auf der HP gewesen und dadurch dir Cronjob nicht angestossen worden. Lösung?

Seit kurzem bin ich wieder dem guten alten EGO-Shooter Wolfenstein – Enemy Territory verfallen. Kurzer Anriss des Spiels: ET spielt im zweiten Weltkrieg. Man ist entweder Allierter oder Axe (also Nazi). Jede Map / Level hat eine bestimmte Aufgabe. Die eine Seite muss diese Aufgabe erfüllen und die andere verhindern. Dabei ist natürlich Waffengewalt im Spiel. Wenn auch in die Jahre gekommen macht diese Spiel einfach nur Spass. Und das die Grafik nicht soooo aktuell und damit auch die Hardwareanforderung nicht so hoch ist, kann das Spiel auch von Gelegenheitskriegshelden wie mir gespielt werden. Sei es drum.

Wenn man also so rum ballert hier und da, dann möchte man darüber natürlich auch Statistiken haben. Mann will ja sehen wer der beste ist. Und da gibt es im Netz so die einen oder anderen Tools die HTML Seiten generieren. Leider gibt es keine brauchbaren Anleitungen. Da wir just heute ein “solches” Tool zum laufen gebracht haben, möchte ich euch natürlich an unserem Wissen teilhaben lassen.

Wir haben uns für das Tool ETS — Wolfenstein: Enemy Territory Statistics entschieden. Diese stammt von Vladi Shabanski und kann hier geladen werden. Vorraussetzung ist ein Webserver der Pearl unterstützt und eine laufender Enemy Territory Server. In unserem Fall handelt es sich um einen regulären Windows PC mit Xaamp (Ein Packet das nur installiert werden muss, und schon läuft der Webserver) naja und ET natürlich.

• Als erstes muss in der server.cfg das Logging aktiert werden. Das geschieht mit folgendem Eintrag (Eventuell schon vorhanden und muss nur angepasst werden). Nach Serverneustart werden die Logfiles (etserver.log und etconsole.log) entweder im Ordner etmain oder des jeweiligen MODs gespeichert (z.B. etpub).

// LOGGINGetserver
set g_log “etserver.log” // Game loggingset
g_logsync 0
set logfile 2 // Console logging ( 1: enable 2: enable and sync )

• Jetzt ETS downloaden und entpacken. Ihr erhalten die Ordner ets_lib, scrennshots und themes. Ausserdem eine Reihe von Dateien. Alle Dateien im Haupverzeichnis und den Ordner ets_lib in den Ordner c:\apache\bin\ kopieren. Jetzt wird der Editor (z.B. Notepad) gestartet und folgendes Eingetragen:

set ETS_LOG_FILE=C:\ETInstallationspfad\etmain\etserver.log
set ETS_PB_FILE=C:\ETInstallationspfad\etmain\etconsole.log
set ETS_OUTPUT_DIR=C:\xampp\htdocs\etstats
C:\xampp\apache\bin\ets.pl

Hier natürlich die Pfade entsprechend deiner Installation anpassen. Dann das ganze abspeichern (z.B. unter ets_config.bat).

• Anschließend zum Test die ets_config.bat ausführen (Doppel Klick) und “hoffen” das es klappt. Eventuell fragt Windows womit die Datei ets.pl gestartet werden soll. Hier muss dann die perl.exe ausgewählt werden. Läuft das ganze, kann man z.B. über den Aufgabenplaner (Start / Alle Programme / Zubehör) einstellen das die ets_config.bat z.B. alle halbe Stunde ausgeführt werden soll.

Fertig, ab jetzt läßt sich über localhost/etstats (oder halt über die Domain / IP-Adresse über die euer Server erreichbar ist) die Statistik eurer kämpfe ansehen.

Downloads:

• Enemy Territory Statistics

WordPress ist und bleibt mein Favorite-CMS oder Blogsystem. Da ich sicher nicht der einzige bin (;o)) hier ein Workaround wiederaufgelegt der vielleicht auch anderen helfen wird.

Vor bereits etwas längerer Zeit loggte ich mich in mein WordPress ein um einen neuen Artikel zu schreiben und musste zu meinem Erschrecken feststellen das mein Dashboard vollkommen leer war. Das Dashboard verschafft dem WordPress Nutzer einen Überblick über die erstellten Artikel, gemachten Kommentaren und über die Neuigkeiten in der WordPress Welt. Eine längere suche über Google und auch das WordPress Forum konnte mir nicht helfen. Heute hatte ich aber endlich wieder Zeit mich damit zu beschäftigen.

Zu erste installierte ich eine neue frische WordPress Installation in einem neuen Ordner und freut mich, das Dashboard zu sehen. Es lag also schon mal nicht an dem Server.

Weiter getestet und dafür gesorgt das auf der neuen Installation die “alte” MySQL Datenbank aufgerufen wird (also praktisch die WP-Config überschrieben). Das Dashboard war weg. Es konnte also auch nicht an den Dateien auf dem Server liegen, der Fehler musste irgendwo in der MySQL Datenbank liegen. Zu guter Letzt hab ich dann einen neuen Nutzer eingerichtet und auch dieser verfügte über ein Dashboard.

Also wußte ich, es liegt ein Fehler in der Datenbank vor, der sich auf meinen Nutzer bezieht. Ich habe mich dann über PHPMyAdmin in die MySQL Datenbank eingeloggt und mit die Tabellen “wp_users” und “wp_usermeta” angeschaut. Unter “wp_usermeta” waren für meinen Nutzer diverse Einträge mit dem Suffix _dashboard vorhanden. Diese Einträge löschte ich und loggte mich erneut in das Backend ein. Uns … ta daaaaa … das Dashboard war auch für mich wieder da.

Ein Beitrag aus der 2nd Edition. Noch recht aktuell.

Das Projekt frittter.de lebt von den Kommentaren der User. Ganz im Gegensatz zu faulthiel.de wo ich lange keine Kommentare zugelassen habe. Bis jetzt ;o) Leider gehört Spam zum Internet wie die Pfeife zu Sherlok Holmes. Daher musste ich mich um eine Plugin zu Spambekämpfung  kümmern.

Kandidat Nr 1: Comment Spamtrap fügt dem Kommentarfeld zwei Eingabefelder hinzu die aber per CSS ausgeblendet werden. Die Spam-Roboter befüllen diese Eingabefelder und outen sich damit als Spammer. Leider hat dieses Plugin nicht funktioniert, da jedes Kommentar als Spam markiert wurde. Also durchgefallen.

Kandidat Nr 2: Defensio Anti-Spam funktioniert ausserhalb meiner WordPress Installation und wird über einen API angebunden. Angeblich Kostenlos kostet das Produkt 250 Dollar im Jahr wenn man über 25 000 Posts kommt….komm ich vermutlich nicht. Aber … argh.

Kandidat Nr 3 – 30: **CAPTCHA ** ist defintiv auch keine alternative für mich. Warum? Weil ich Captchas falsch und doof finde. Ich sehe nicht ein warum sich viele User verbiegen müssen um mir Arbeit zu ersparen.

Und so bin ich nach langer Suche wieder bei Sieger gelanden

Spam Karma 2: Spam Karma 2 wird zwar leider seit 2009 nicht mehr weiterentwickelt, scheint aber auch im aktuellen WordPress fehlerfrei zu laufen. Nachteilig bisher war, das Spamkarma relativ viel Speicherplatz in der MySQL Datenbank nutzt. Das macht sich dann bei vielen Blogs auf einem Host oder bei einem Datenbankumzug schon stark bemerkbar.