Interrogando qualsiasi altro feed da WordPress tutto funziona regolarmente ma considerando che GitHub fornisce i suoi feed RSS su protocollo sicuro http (HTTPS), ne ho dedotto che il problema fosse proprio nel certificato.

Forse perchè l’authority per la certificazione non risulta tra quelle previste dal server su cui risiede WordPress, oppure perchè c’è una qualsiasi altra configurazione del server che non consente una validazione del Certificato di Sicurezza, il risultato è che non sarebbe possibile interrogare un feed RSS di GitHhub, ottenendo in compenso questo simpatico messaggio di errore:

RSS Error:
WP HTTP Error: SSL certificate problem, verify that the CA cert is OK.
Details: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed

Ma come ben sapete “non è possibile” non fa parte del mio vocabolario, quindi mi sono spulciato il codice della classe Http di WordPress e facendo un po’ di reverse engignering sono arrivato alla soluzione del problema.

Per evitare che WordPress faccia la verifica del certificato basta mettere nel file functions del proprio tema questa semplice riga di codice:

add_filter('https_ssl_verify', '__return_false');

Per riuscire però ad effettuare i commit attraverso il Proxy che non consente l’acceso ssh al server github.com ho fatto diverse ricerche su internet, provando le più diverse strade.

C’era chi suggeriva di creare un file wrapper per il proxy seguendo un procedimento alquanto semplice:

• Installare netcat
• creare uno script da shell collocandolo nella directory bin/ dell’utente che riportava in sintesi questo comando “nc -x${PROXY_IP}:${PROXY_PORT} -X5 $*“
• configurare il parametro core.gitproxy indicando il nome del file precedentemenet creato.

Per me non ha funzionato e comunque questa procedura a mio avviso poteva essere  semplificata ulteriormente utilizzando questi due semplici comandi eseguiti da shell.

EXPORT http_proxy=http://myproxy:8080
EXPORT https_proxy=http://myproxy:8080

Non li metterei come valori persistenti perchè, usando il notebook su diverse reti rischierei di non raggiungere il proxy specificato con conseguenza dell’interruzione della navigazione.

Comunque non ha funzionato. Quindi ho cercato una nuova soluzione al problema.

Un altro sito suggeriva di usare l’url proposto da github nella versione https al posto di quello ssh.

Ho fatto un tentativo e non riuscivo nemmeno a clonare il repository remoto ricevendo come risposta “warning: remote HEAD refers to nonexistent ref, unable to checkout.“. Quindi ho temuto che fosse un problema del mio repository remoto. Per fortuna anche con il repository di JQuery mi segnalava lo stesso errore. E lo faceva con qualsiasi repository provassi a clonare. Quindi il repository non aveva problemi.

Ho provato a fare un mix tra le soluzioni “installazione netcat” e “https al posto di ssh” ma comunque non ho avuto il risultato sperato quindi ho continuato nella ricerca della soluzione fino ad incappare in questa discussione!

Grazie a quanto è scritto nella discussione precedente ho cominciato a fare un po’ di prove giocando sull’url per la richiesta del repository.

La soluzione in fondo era più semplice di quanto si pensasse.

Partendo dall’url di aggiornamento del repository fornito da github in formato https (https://user@github.com/user/repository.git), ho inserito anche la password dell’account github e ho fatto viaggiare la richiesta su protocollo http (non sicuro). Quindi l’url utilizzato in fine è stato:

http://user:password@github.com/user/repository.git

In questo modo ha funzionato tutto correttamente e sono libero di aggiornare il mio framework da, come direbbero gli americani, “ognidove”! :)

Spulciando un po’ il codice e la documentazione di WordPress, ci sono tanti modi descritti per risolvere il problema, ma tra quelli che prediligo c’è la modalità SQL, che richiede tu abbia le credenziali di accesso al tuo DB, che se non ricordassi sono nel file wp-config.php nella root del sito, e principlamente non richiede la scrittura di codice PHP (almeno evitiamo di scriverlo quando non è realmente necessario :D )!

Questa modalità SQL è molto semplice in quanto WordPress autentica un utente anche accettando una password codificata in MD5 (guardatevi il codice del metodo wp_check_password(), nel file /wp-includes/pluggable.php).

Quindi accediamo alla nostra console di MySQL (di solito utilizzo MySQL Workbench del quale non riesco più a farne a meno), e stabiliamo la connessione alla nostra banca dati, infine, presupponendo di avere un’installazione base di WordPress ci dovremmo ritrovare con delle tabelle con prefisso wp_, quindi eseguiamo subito una bella query di selezione:

select * from wp_users

prendiamo nota dell’ID dell’utente con ruoli di amministrazione, nel mio caso l’ID equivaleva a “1″. Poi eseguiamo la seguente query:

update wp_users set user_pass = md5('mia nuova password') where ID= 1;

Come direbbero i francesi “Les jeux sont fait!”

La soluzione è servita!

Presupponendo che l’installazione di wordpress si presenta con la modalità predefinita di permalink (?page_id=0000) si vuole dirottare la pagina con ID 1234 verso il sito http://example.com.

Ecco le considerazioni da cui partire:

1. Si presuppone che sul webserver sia installato e ben configurato il modulo mod_rewrite di Apache.
2. La struttura dell’url costruito da WordPress per arrivare alla pagina 1234 è http://miosito.it/?page_id=1234
3. La regola dovrà prevedere che tutte le richieste che arrivano alla suddetta pagina dovranno essere dirottate verso il sito http://example.com
4. Per una corretta indicizzazione sui motori di ricerca la pagina 1234 dovrà rispondere con un codice di Redirect 301 (la pagina è stata trasferita altrove)

La regola di rewrite da utilizzare per il suddetto scopo è la seguente:

RewriteEngine on
RewriteCond %{QUERY_STRING} page_id=1234
RewriteRule .* http://example.com [R=301,L]

Maggiori informazioni sulle Rewrite Rules e sul mod_rewrite potete trovarle nella documentazione ufficiale.

Poichè il numero di articoli era troppo elevato per effettuare un’operazione individuale ho dovuto fare un’operazione di massa utilizzando degli script mySQL.

Presupponendo di avere un’installazione di base di WordPress con una configurazione del DB di default ( prefisso alle tabelle wp_ ), la prima cosa da fare è identificare la categoria di nostro interesse:

select * from wp_terms where name='Mia Categoria';

avremo quindi le seguenti informazioni di nostro interesse:

1. term_id: chiave primaria della tabella. Questa informazione è la più importante per noi.
2. name:  è il nome “Friendly” della categoria o del tag.
3. slug: invece è il nome così come viene utilizzato da WordPress per identificare negli url in modo univoco la categoria o il tag.

In questo momento però abbiamo un serio problema, “Mia Categoria” potrebbe essere un tag oppure una categoria. Sì perchè WordPress, conserva queste due informazioni nella stessa tabella, per cui dobbiamo arrivare ad identificare l’informazione di categoria. Tale informazione è conservata nella tabella wp_term_taxonomy.

Dalla tabella wp_term_taxonomy prendiamo in considerazione queste 3 informazioni:

• term_taxonomy_id: la primary key della tabella
• term_id: che è in realzione uno a molti con la tabella wp_terms (un term_id della tabella wp_terms, molti term_id della tabella wp_term_taxonomy)
• taxonomy: che identifica il tipo di tassonomia (categoria, tag).

select
   taxonomy.term_taxonomy_id,
   taxonomy.term_id,
   terms.name,
   terms.slug
from
   wp_terms terms left join wp_term_taxonomy taxonomy on terms.term_id = taxonomy.term_id
where
   taxonomy.taxonomy = 'category' and
   terms.name = 'Mia Categoria';

A questo punto abbiamo selezionato solo le tassonomie “Mia Categoria”. Se però le categorie “Mia Categoria” fossero più di una avrebbero certamente uno slug differente quindi si potrebbe definire la condizione utilizzando terms.slug anzichè terms.name.

Dunque abbiamo a nostra disposizione l’informazione chiave: term_taxonomy_id.

function applicaSeparatore(importoNumerico){
  var importo = importoNumerico.toString();
  if(importo.length>3){
    importo = importo.split('',importo.length).reverse().join('').replace(/([0-9]{3})/g,'$1.');
    importo = importo.split('',importo.length).reverse().join('');
  }
  return importo;
}

Di solito uno accetta di installare questo plugin, specialmente quando si utilizza Skype a scopo professionale.

Mi è successo però che, in un’applicazione web che stavo sviluppando, il numero di telefono nascondeva al click un’operazione accessoria che invece mi veniva nascosta dal codice generato dal plugin di Skype per l’instant call.

Analizzando il codice ho risolto utilizzando semplicemente queste due regole di stile nel mio CSS:

span.skype_pnh_container {display:none !important;}
span.skype_pnh_print_container {display:inline !important;}

Di seguito è rappresentata la funzione Replace da copiare ed incollare in un Modulo ed utilizzabile da Visual Basic 5 quanto dalle versioni precedenti.
Tale funzione utilizza la stessa sintassi della funzione introdotta con il Visual Basic 6 così da consentire eventuali migrazioni delle procedure che ne fanno utilizzo in modo trasparente (rimuovendo quindi solo la funzione dal modulo).

Public Function Replace(ByVal Expression As String, Find As String, sReplace As String, Optional Start As Long = 1) As String
  Dim S As String
  Dim I As Integer
  For I = Start To Len(Expression)
    S = UCase(Mid(Expression, I, Len(Find)))
    If S = UCase(Find) Then
       Expression = Left(Expression, I - 1) & sReplace & _
          Mid(Expression, I + Len(Find))
       I = I + Len(sReplace) - 1
    End If
  Next
  Replace = Expression
End Function

L’algoritmo che dovetti implementare per cancellare ciascun file fa uso di una API di Windows ed il codice è simile a quello che segue:

Private Type SHFILEOPSTRUCT
 hWnd As Long
 wFunc As Long
 pFrom As String
 pTo As String
 fFlags As Integer
 fAborted As Boolean
 hNameMaps As Long
 sProgress As String
End Type
Private Const FO_DELETE = &H3
Private Const FOF_ALLOWUNDO = &H40
Private Declare Function SHFileOperation Lib "shell32.dll" Alias
  "SHFileOperationA" (lpFileOp As SHFILEOPSTRUCT) As Long

Public Function SpostaNelCestino(file_name As String)
  Dim SHFileOp As SHFILEOPSTRUCT
  With SHFileOp
   .wFunc = FO_DELETE
   .pFrom = file_name
   .fFlags = FOF_ALLOWUNDO
  End With
  SHFileOperation SHFileOp
End Sub

Rimarcando la mia fama tra gli amici per non riutilizzare mai software impacchettato e freeware, ma sempre propenso a sviluppare internamente quella specifica funzione ad-hoc, decisi di svilupparmi una procedura per lo splitting del file in una serie di n files di una determinata dimensione ed ovviamente sviluppai anche la funzione per la ricongiunzione dei files in un unico grande file.

Il frammento di codice che trovate di seguito, è estratto da un progetto leggermente più grosso ed ho preferito riportare semplicemente l’essenziale per comprendere come funziona il tutto:

Dest = FreeFile
 MergedFile = "C:\Merged.txt"
 Offset = 1
 Open MergedFile for Binary Access Write Lock Read As FDest
 For I=Lbound(filesArray) to UBound(filesArray)
 FSorg = FreeFile
 Open filesArray(I) for binary Access Read Lock Write as FSorg
 S=String(Lof(FSorg),chr(0))
 Get FSorg,1,S
 Close FSorg
 Put FDest,Offset, S
 Offset = Offset + len(S)
 next
 Close FDest

Questa procedura preleva da un array filesArray i nomi dei files da concatenare e li salva in un unico file indicato nella variabile MergedFile