Ieri, preso dalla voglio di utilizzare quel software con quella bellissima icona, mi son detto:
”ma i sorgenti sono liberi o devo ancora pregare l'autore perche' sistemi quel problema con WordPress?”
Bene, ho scoperto che il progetto era in Sourceforge e...swluap! I sorgenti erano gia' belli e scompattati sul mio disco!
Cosa me ne sarei fatto ? Beh, almeno capire dov'era il problema (o i problemi):
a) Dopo il salvataggio di un POST, l'applicazione generava un'eccezione...”document data not valid at root level: line 1 row 1”.
b) I post alla fine apparivano nel blog ma ... con data 01-01-1970
Premetto che utilizzo WordPress 1.2.2 (per l'altro mio blog) del quale sfrutto XMLRPC per chiamare le API MovableType.
Il debugging non e' stato semplice (almeno per me) perche' non e' sufficiente (Andrea smentiscimi) mettere su la solution con tutti i reference
ma anche copiare i file necessari affinche' lo script di Post-Build funzioni...
Come ho fatto ? Beh, ho farcito il codice (nella dll del suddetto plugin per MT) con delle System.Diagnostic.Debug.WriteLine(); e, munito del buon DebugView (inutile se avessi aggiunto la chiave “EnableLogging” a “true” nel file imho.exe.config) .
Il problema A, per farla breve, era nella risposta di WordPress alla chiamata XMLRPC: invece di ritornare xml “puro”, antecedeva a questo, la seguente stringa:
Array
(
[0] => Technology
[1] => Blog
)
Ovvero le categorie alla quale apparteneva il post appena inserito.
Il parser XML (e la successiva query XPath) di IMHO fallivano proprio per questa stringa inattesa.
Soluzione: di seguito postero' il pezzo di codice comprensiva della mia patch (in bold) ... so che non e' pulitissima ma...magari la possiamo ottimizzare/migliorare insieme
[...omissis...]
// leggo la risposta
using( HttpWebResponse response = request.GetResponse() as HttpWebResponse )
{
// ritorna sempre OK
if ( response.StatusCode != HttpStatusCode.OK )
throw new EngineException(string.Format( ResTable.GetString( "STR_BadResponseCode" ), response.StatusCode ) );
// leggo la risposta ma gestisco solo il fault
using( Stream responseStream = response.GetResponseStream() )
{
//Tolta la using e modificato il secondo parametro in modo da renderlo auto-//adattativo all’encoding
StreamReader reader = new StreamReader( responseStream, true);
//Begin: Patch BY Igor Antonacci
reader = ParseResponse(reader);
//End: Patch BY Igor Antonacci
DeserializePostXml( reader );
}
}
[...omissis...]
private StreamReader ParseResponse(StreamReader reader)
{
StreamReader parsedReader = null;
if(reader!=null)
{
string mystream = reader.ReadToEnd();
int xmlPos = mystream.IndexOf(@"<?xml ");
mystream = mystream.Substring(xmlPos,mystream.Length-xmlPos);
MemoryStream ms = new MemoryStream(Encoding.UTF8.GetBytes(mystream));
parsedReader = new StreamReader(ms);
}
return parsedReader;
}
In sostanza ho voluto lasciare il codice in modo che, togliendo l'unica chiamata al mio metodo (ParseResponse), il tutto continuasse a funzionare.
Nel metodo non faccio altro che eliminare l'eventuale parte prima dell'xml.
Dopo aver patchato questa parte...sono passato al problema B...qui non mi dilunghero'; Vi basti sapere che ho modificato
alcuni file PHP dell'implementazione dell'XMLRPC di WordPress: questi si aspettavano una data senza separatori tra anno e mese
e tra mese ed anno (tipo: 20050929T17:47Z) mentre IMHO le inviava con il segno “-” come separatore (2005-09-29T17:47Z).
Il motivo sta nella blanda(?) definizione delle specifiche dell'XMLRPC su questo fronte...e' un problema sentito da molti, pare.
Corretta l'espressione regolare (ovvero aggiunta quella “giusta” a quella esistente in modo da fare fallback), le cose sono andate
come dovevano...e finalmente IMHO 1.2.1964 (o direi 1.2.1965 ? :D) e' utilizzabile anche sul mio blog WordPress...
Infine ho ricompilato la DLL in modalita' “Release (en-us)” e ... et voila'.
Nell'attendere critiche e correzioni circa il codice da me introdotto, faccio i miei complimenti ad Andrea per la pulizia
del codice con il quale ha portato avanti TUTTO il progetto IMHO ...COMPLIMENTI!
Igor Antonacci