Fehlerhafte Links in der Sidebar bei WordPress

Vorhin ist mir aufgefallen, dass die Links zu den letzten Kommentaren in der Sidebar fehlerhaft waren. Sie zeigten sogar in ein falschen Blog. Ich dachte, es läge an der WordPress MU Installation. Also spielte ich mit den Einstellungen herum und verschlimmbesserte nur noch alles. Also ging ich einen anderen Weg und versuchte dem Fehler auf die Schliche zu kommen, in dem ich die Funktionen testete. Das ist aber recht schwierig, da das WordPress Backend mittlerweile riesig ist und wenn man nicht Up-To-Date ist, hat man absolut keine Chance. Also den Königsweg gegangen und nach und nach alle Plugins deaktiviert und schon hatte ich den schuldigen gefunden: FeedWordpress

Das Plugin sorgt dafür, dass der RSS Feed anderer Blogs ausgelesen werden und hier als eigene Einträge erscheinen. Damit der Fehler reproduzierbar ist, müssen folgende Voraussetzungen erfüllt sein:
– Bei FeedWordpress muss unter Einstellungen -> „Posts & Links“ -> Permalink auf „point to the copy on the original website“ stehen
– der letzte Eintrag der Seite muss ein per Feed importierter Eintrag sein
– Das Widget „Recent_Comments“ oder jede andere Funktion, dass einen Permalink per „get_permalink()“ zu holen versucht, muss „nach“ diesem bestimmten Beitrag ausgeführt werden

Um den Fehler zu verstehen, schauen wir kurz in die „feedwordpress.php“ im Pluginverzeichnis.
Dort steht folgendes:

function syndication_permalink ($permalink = '') {
	if (get_option('feedwordpress_munge_permalink') != 'no'):
		$uri = get_syndication_permalink();
		return ((strlen($uri) > 0) ? $uri : $permalink);
	else:
		return $permalink;
	endif;
} // function syndication_permalink ()

In unserem Fall ruft er also die Funktion „get_syndication_permalink()“ ohne Parameter auf:

function get_syndication_permalink ($id = NULL) {
	list($u) = get_post_custom_values('syndication_permalink', $id); return $u;
}

Als Defaultwert ist NULL angegeben. Ein Blick in den WordPress-Codex verrät, dass er das Benutzerdefinierte Feld des aktuellen Eintrags laden versucht. Das ist logischerweise noch der aus dem Feed importierte Eintrag und daher lädt er eine falsche URL.

Um das Problem zu beheben, einfach den Code oben durch folgenden ersetzen:

function syndication_permalink ($permalink = '') {
	$id = url_to_postid($permalink);
	if (get_option('feedwordpress_munge_permalink') != 'no'):
		$uri = get_syndication_permalink($id);
		return ((strlen($uri) > 0) ? $uri : $permalink);
	else:
		return $permalink;
	endif;
} // function syndication_permalink ()

Die „url_to_postid()“ ist eine WordPress-eigene Funktion. Nun funktioniert es wieder. Darauf muss man erstmal kommen!

C# – PrintDialog.ShowDialog() funktioniert nicht

Bin gerade auf ein sehr merkwürdiges Problem gestoßen, dass doch locker eine Stunde wertvolle Lebenszeit gekostet hat.
Folgender Code:

PrintDialog pd = new PrintDialog();
if (pd.ShowDialog() == DialogResult.OK)
{
    // do nothing

}

Nichts großes, sollte einfach nur so ein Druckerfenster öffnen, wo der Drucker ausgewählt wird etc. Leider öffnete sich der erhoffte Dialog nicht. Der Debugger läuft dahin, aber er führt den ShowDialog() einfach nicht aus.

Wenn ich die Eigenschaft „UseEXDialog“ auf „true“ setze, funktioniert es.
Jedoch wollte ich nicht den XP-Dialog, sondern den anderen. Auch im Netz fand ich keine wirkliche Lösung.
Da diese Codezeilen aus einem bestehenden Projekt stammen, habe ich kurzerhand neue Projekte in den Frameworks 2.0, 3.5 und 4.0 angelegt. Jeweils mit dem Codeschnippsel oben. Und siehe da, es funktioniert problemlos, in jeder Frameworkversion. Nun die Unterschiede gesucht.

Fündig wurde ich den Projekteigenschaften unter „Build“ bzw. „Erstellen“.
Ich muss dazu sagen, dass die Applikation vorher auf einem anderen Rechner mit einem 32-bit Windows entwickelt wurde. So stand hier unter dem Punkt „Platform target:“ (auf Deutsch vermutlich Zielplattform) „Any CPU“.
Stellt die Anwendung hier auf 32-bit (x86) und der PrintDialog() wird hervorragend funktionieren. x64 oder Any CPU funktioniert nicht.
Auf so etwas muss man erstmal kommen, warum das so ist, keine Ahnung.

So habe ich noch mal in der MSDN nachgeschlagen:

This class may not work on AMD64 microprocessors unless you set the UseEXDialog property to true.

Ich bin zwar nun nicht der technisch versierte Mensch, aber für mich hört sich das nach einem Problem mit einem AMD Prozessor an, ich habe jedoch einen Intel (ich lasse es mir aber dennoch gerne erklären).

Lokaler Pfad bei SQLite Datenbank und ASP.NET

Ich probiere mich gerade in ASP.NET und um nicht gleich einen SQL-Server aufsetzen zu müssen, nutze ich SQLite. Die Abfragen sind ähnlich und zum Rumspielen reicht das dicke hin. Zudem habe ich schon ein paar Erfahrungen mit einem anderen Tool gesammelt. Nun hatte ich folgendes Phänomen, ganz am Anfang hatte ich die Datenbank erstellt mit irgendwelchen Dummyeinträgen und ein bischen mit den Ajaxelementen von Visual Studio rumgespielt.
Das hat auch gut geklappt, das auslesen der Daten lief im Hintergrund per SQLiteConnection(). Dann habe ich mir ein reines HTML Formular gebastelt und wollte hier eine Art Login ausprobieren. Auf einmal kam jedes mal die Fehlermeldung, dass die Datenbank „Users“ nicht gefunden wurde (Users war die von mir erstellte).

System.Data.SQLite.SQLiteException: SQLite error
no such table: Users
   bei System.Data.SQLite.SQLite3.Prepare(SQLiteConnection cnn, String strSql, SQLiteStatement previous, UInt32 timeoutMS, String& strRemain)
   bei System.Data.SQLite.SQLiteCommand.BuildNextCommand()
   bei System.Data.SQLite.SQLiteCommand.GetStatement(Int32 index)
   bei System.Data.SQLite.SQLiteDataReader.NextResult()
   bei System.Data.SQLite.SQLiteDataReader..ctor(SQLiteCommand cmd, CommandBehavior behave)
   bei System.Data.SQLite.SQLiteCommand.ExecuteReader(CommandBehavior behavior)
   bei System.Data.SQLite.SQLiteCommand.ExecuteReader()
   bei ASPGuestbook.LoginForm.checkLogin() in ...\LoginForm.aspx.cs:Zeile 57.

Unter Visual Studio konnte ich die SQLite Datenbank ohne Probleme bearbeiten. Die Datei war auch im selben Verzeichnis. Ich hatte mir auch per AppDomain.CurrentDomain.BaseDirectory das Verzeichnis ausgeben lassen. Hat auch alles gepasst.
Mein Befehl zum Öffnen lautete so:

SQLiteConnection sqlCon = new SQLiteConnection("Data Source=datenbank.db3;Password=12345;");
sqlCon.Open();

Natürlich schön im try / catch Block verpackt, es kam aber keine Fehlermeldung. Hat einen Moment gedauert bis ich dahinter kam. Und zwar hat die SQLite Erweiterung die ich nutze die dumme Angewohnheit, wenn Data Source nicht existiert, dass er eine leere Datenbank anlegt. In dieser leeren Datenbank gibt es natürlich nicht die Tabellen und folglich der Fehler. Angelegt hat er diese leeren Datenbanken übrigends unter

C:\Programme\Microsoft Visual Studio 9.0\Common7\IDE

Darauf muss man erstmal kommen..
So funktioniert es dann, ob es die optimale Lösung ist, bezweifel ich.

SQLiteConnection sqlCon = new SQLiteConnection("Data Source=" + AppDomain.CurrentDomain.BaseDirectory + "bin\\datenbank.db3;Password=12345;");
sqlCon.Open();

Das Problem lässt sich sicherlich auch auf andere Sprachen adaptieren. Bei einem richtigen SQL Server fällt das ja sowieso weg, aber nervig wars trotzdem!