realloc's asylum | realloc's asylum

WordPress + Database = WPDB

realloc — Thu, 09 Sep 2010 15:40:23 +0000

Mi risulta facile immaginare come sia possibile l’elevato numero di hack per WordPress che usano il database ma non le funzionalità proprie del CMS. Tuttavia, solo perché qualcosa apparentemente funziona non significa che sia giusto o che funzioni anche su altre installazioni.

Con un paio di martellate si può adattare tutto anche allo sviluppo di software o di componenti per WordPress. Almeno questa è l’impressione che ho quando vedo alcune strutture che in certi forum compaiono con la descrizione “non funziona”. Gli errori si potrebbero però evitare sin dall’inizio – soprattutto lavorando con il database – se si usassero funzionalità testate.

In WordPress esiste una classe che mette a disposizione tutto ciò che è necessario per usare un database. La classe WPDB non si dovrebbe però utilizzare direttamente perché esiste già un’istanza a cui si può ricorrere tramite la variabile globale $wpdb. E’ importante sapere che con le funzionalità di questo oggetto non si possono soltanto inoltrare richieste alle tabelle di WordPress ma sono anche disponibili tutti i contenuti del database della configurazione.

Oltre al metodo generico get_results, che è da preferire alla funzione mysql_query di PHP, ci sono anche metodi per richieste diverse e altri per la manipolazione, la modifica, l’inserimento e la cancellazione dei dati. A questo proposito vorrei anche evidenziare i meccanismi di WordPress che offrono più sicurezza contro SQL-Injections.

Per ragioni di sicurezza si consiglia spesso di cambiare il prefisso delle tabelle di WordPress. Sono completamente d’accordo tuttavia – per fare un esempio – una richiesta diretta alla tabella wp_options non funzionerebbe più. WPDB però referenzia già le tabelle base dell’installazione, così è possibile scrivere statement SQL in modo più generico. Alla fine esiste anche la proprietà $wpdb->prefix che conosce anche il prefisso usato.

Similar Posts:

Visualizzare dati xml con wordpress

realloc — Tue, 07 Sep 2010 15:23:12 +0000

Strano titolo? Lo trovo anch’io. Ma “visualizzare dati xml con wordpress” è solo un esempio dei longtail con cui i motori di ricerca mandano i visitatori al mio blog. Non ho problemi con questo, anzi! Diventa solo problematico quando riesco a capire di che cosa si tratta e vedo che viene usato il codice di articoli preistorici, che ovviamente non è più attuale.

WordPress fornisce diverse possibilità sopratutto in questo caso. Prima di cominciare però dovrebbe essere chiaro come si elaborano i dati (premesso che i dati siano disponibili su un server remoto) e dove li si vuole visualizzare. Quando l’obiettivo è mostrarli soltanto in una pagina, si può cercare una soluzione con un nuovo Page-Template. Per visualizzare l’output regolarmente prima o dopo il content dell’articolo si può cercare una soluzione con un altro filtro per the_content().

La terza possibilità è l’uso dello Shortcode API di WordPress, flessibile e potente. In un articolo si scrive per esempio [countryinfo] e WordPress proverà a eseguire la funzionalità nel caso in cui sia definito uno shortcode corrispondente. Con un parametro l’output è ancora più flessibile: [countryinfo country="de"]. Per abilitare WordPress dovete aggiungere qualche riga di codice nel file functions.php del tema o in un proprio plugin.

In fondo si definisce soltanto una funzione che si registra con add_shortcode. In questa funzione si può usare shortcode_atts per elaborare i parametri disponibili dopo l’uso in un array. Si deve sapere però che l’array viene normalizzato, vale a dire ridotto ai parametri definiti. In più la funzione si aspetta che il nome dei parametri sia lowercase (minuscolo).

function my_countryinfo ($atts) {
extract (
shortcode_atts (
array (
"lang" => "de",
"country" => "DE",
),
$atts
)
);
$output = "";
$result = wp_remote_get ("http://ws.geonames.org/countryInfo?lang=" . $lang . "&country=" . $country);
if (!is_wp_error ($result)) {
// $result['body'] contains the requested content
$output = $result["body"];
}
return $output;
}
add_shortcode ("countryinfo", "my_countryinfo");

?>

L’esempio (una richiesta a GeoNames) fa esattamente quanto detto finora. La funzione extract esporta le variabili nel namespace della funzione. In alternativa, si può usare l’output di shortcode_atts anche direttamente. Resta aperta la domanda su come si elaborano file remoti. Per non scoprire l’acqua calda ed evitare problemi, è consigliato l’uso della HTTP-API di WordPress. Anche questo è mostrato chiaramente nell’esempio.

L’ultimo passo è l’elaborazione dei dati. PHP 4 è morto! Viva PHP 5 e SimpleXML o JSON, a seconda del formato preferito. Se intendete lavorare con RDF leggete anche l’articolo XML, JSON e RDF. Il resto del lavoro però lo lascio a voi. Buon divertimento con l’implementazione della vostra soluzione.

Similar Posts:

XML, JSON e RDF

realloc — Tue, 07 Sep 2010 09:28:24 +0000

Grazie alle funzioni native, l’elaborazione di XML (eXtensible Markup Language) e JSON (JavaScript Object Notation) non costituisce più un problema. Anche se JSON in fondo è pensato per applicazioni Ajax , preferisco il formato anche in PHP quando voglio e posso evitare l’overhead dei dati XML.

Il Geonames-Webservices è un buon punto di partenza per qualche esempio perché presenta le funzioni del servizio che sono in grado di fornire i dati in almeno questi due formati. In più le funzioni di Geonames sono probabilmente molto interessanti per tanti Webmaster. Chi è interessato a richieste diverse dovrebbe consultare la documentazione del Webservice.

Per una richiesta generica con la query london basta l’URL seguente:

http://ws.geonames.org/search?q=london&maxRows=10

Il parametro maxRows controlla il numero dei risultati. Per definizione il risultato viene fornito in XML. Se si vuole il formato JSON si deve aggiungere il parametro type:

http://ws.geonames.org/search?q=london&maxRows=10&type=json

Dando un’occhiata più specifica alla lista dei Geonames-Services si scopre che si può richiedere anche il formato RDF (Resource Description Framework). Chiunque voglia entrare nel mondo del Semantic Web dovrebbe dedicarsi a prendere confidenza con questo formato. Se non avete ancora idea di che cosa si tratti, un buon punto di partenza è DBpedia.

Le funzioni ovvero i metodi SimpleXML di PHP falliscono con RDF. Anche se il formato viene chiamato RDF/XML la classe SimpleXML presenta problemi con i due punti negli XML-Entities. Le soluzioni però ci sono. Personalmente preferisco Arc. Il pacchetto va semplicemente caricato e messo a disposizione sul server.

Come elaborare con PHP tutti e tre i formati descritti, è illustrato dal code seguente:

$url = "http://ws.geonames.org/search?q=london&maxRows=10";
$xml = simplexml_load_file ($url);

echo "Ausgabe des SimpleXML-Objects:

" . 
     print_r ($xml, TRUE) . 
     "

";

$json = file_get_contents ($url . "&type=json");
$arr = json_decode ($json);

echo "Ausgabe der JSON-Daten als Array:

" . 
     print_r ($arr, TRUE) . 
     "

";

include_once ("arc/ARC2.php");
$parser = ARC2::getRDFParser ();
$parser->parse ($url . "&type=rdf");
$triples = $parser->getTriples ();

echo "Ausgabe der RDF-Daten als Array:

" . 
     print_r ($triples, TRUE) . 
     "

";

?>

Chi è interessato all’output delle richieste può vedere anche lo script in azione.

Have fun!

Similar Posts:

Pimp a WordPress-Standard-Widget

realloc — Fri, 03 Sep 2010 17:18:04 +0000

Poco tempo fa ho presentato un hack che nasconde il Link-Widget nella homepage del blog. La decisione di cercare una soluzione del tipo “quick & dirty” era in parte dovuta al mio gusto personale e in parte alla curiosità di capire che cosa succede all’interno di WordPress una volta attivato un widget. Alla fine ho presentato una soluzione non molto bella e nemmeno raccomandabile in un ambiente più complesso.

A questo punto, prima di presentare una soluzione un po’ più elegante, voglio scrivere due righe sui widget. In rete viaggiano tante spiegazioni diverse su cosa sia un WordPress Widget. Ci sono anche articoli che descrivono questa funzionalità come qualcosa a metà strada fra tema e plugin. Ma questa la definirei una semplificazione e, di fatto, non è così!

Naturalmente i widget esistono per definizione per essere presentati nelle sidebar dinamiche. Ma per questo motivo non diventano automaticamente una parte di un tema. Nel controllo dei widget, che si trova nel pannello di amministrazione, i widget restano disponibili, se il codice non si trova nel functions.php del tema, anche quando si cambia il design.

Per un widget il fatto che il suo codice esista nel core di WordPress, nel functions.php del tema o in un file di un plugin, è del tutto indifferente. Importante è solo attenersi alle regole, ovvero seguire la Widget-API. Tra l’altro, personalmente trovo anche la denominazione API un po’ infelice.

Parlerei piuttosto di un Framework o per essere più preciso di una raccolta delle classi con qualche esempio predefinito, gli Standard Widget. Tutti i widget devono estendere la classe WP_Widget e devono implementare pochi metodi per integrarsi bene.

A questo punto la domanda, perché non estendere i widget standard, è ovvia. È possibile determinare da soli quando mostrare un widget e quando no? La risposta è sì … e non solo: alla fine la soluzione risulta non solo efficace ma anche molto semplice.

class MY_Widget_Links extends WP_Widget_Links {

function widget ($args, $instance) {
if (!is_front_page () && !is_home ()) {
parent::widget ($args, $instance);
}
}

}

function mywidgetlinks_load () {
unregister_widget ('WP_Widget_Links');
register_widget ('MY_Widget_Links');
}
add_action ('widgets_init', 'mywidgetlinks_load');

?>

Il codice si può inserire per esempio nel file functions.php del tema e si può spiegare anche con poche parole:

La classe MY_Widget_Links estende il widget standard responsabile per la visualizzazione della blogroll. Il metodo widget che rende l’output controlla prima tramite i tag condizionali se la pagina non è la nostra homepage e, in tal caso, ricorre al metodo della classe parent. Presento poi una funzione che viene triggerata quando i widget vengono inizializzati, che disattiva il widget standard e infine attiva la versione modificata.

Similar Posts:

Parsing link reloaded

realloc — Fri, 03 Sep 2010 16:03:34 +0000

Tre anni fa ho scritto un articolo in tedesco con il titolo Backlinks gecheckt che riceve sorprendentemente ancora una notevole quantità di traffico. Devo ammettere che le informazioni sono già piuttosto vecchiotte e non rappresentano più una soluzione per diverse problematiche nel mondo attuale. Il parsing dei link con le regular expression in realtà è tutt’altro che una buona idea. HTML è context-free e le regular expression non trovano quasi regolarmente nulla.

Più promettenti sono le diverse funzioni DOM già disponibili dall’introduzione di PHP5. Ma l’utilizzo con i siti di oggi, che spesso si servono di codici non validi, presenta ancora qualche insidia. Per fortuna esiste una soluzione che uso da tempo e con la quale si possono evitare le problematiche descritte sopra: il PHP Simple HTML DOM Parser.

Il parsing dei link nei documenti HTML diventa con questa library un gioco da ragazzi. Con i meccanismi di WordPress che aiutano a rilevare pagine remote, chiunque abbia familiarità con la sintassi di jQuery si troverà benissimo. Il mio piccolo esempio mostra come si usa il parser da uno script al di fuori dell’installazione di WordPress. L’obiettivo è mostrare tutti i link della mia homepage con l’attributo nofollow:

require ('../wp-load.php');
require_once ('simple_html_dom.php');

$result = wp_remote_get ('http://lloc.de/');
if (!is_wp_error ($result)) {
$html = str_get_html ($result['body']);
foreach ($html->find ('a') as $a) {
if (isset ($a->rel) && false !== strpos ('nofollow', strtolower ($a->rel))) {
echo $a->href . ' -> ' . $a->rel . '
';
}
}
}

Similar Posts:

La Transients API di WordPress

realloc — Thu, 02 Sep 2010 19:03:59 +0000

Già dalla versione 2.8 di WordPress esiste un meccanismo nel core che permette il caching dei dati: la Transients API. Con poche righe di codice ci si può risparmiare tutto lo stress di funzionalità proprie che servono soltanto a velocizzare un plugin o una pagina con dati già elaborati.

Le funzioni della Transients API sono simili alla WordPress Options API che dovrebbe rendere l’implementazione molto facile. Oltre ai nomi delle funzioni c’è solo una differenza: un parametro aggiuntivo che definisce la scadenza all’inserimento di un transient.

La Transients API ricorre a funzionalità della Options API se per esempio non vengono usati meccanismi di memcache. Dando un’occhiata al codice stesso della API si capisce perché non è detto che i dati verranno salvati nella tabella wp_options. Bisogna tenere in mente solo questo e altre due piccole cose.

Quando la Transients API invece usa la wp_options il primo problema è che la colonna option_name è per definizione un varchar(64). Nomi più lunghi vengono automaticamente accorciati. Non sembrerebbe così drammatico ma è utile sapere che i transients verranno salvati col prefisso _transient_.

Una seconda riga nel db che contiene il timestamp della scadenza assume automaticamente il prefisso _transient_timeout_ che significa che la lunghezza massima effettiva di un nome di un transient è limitata a 45 caratteri. Se si vuole inserire un transient con l’URL nel nome, l’uso di md5() sembrerebbe utile perché genera una stringa di 32 caratteri.

A questo punto serve un piccolo esempio di codice per spiegare come il mio plugin scGeSHi risolve la problemtica quando rileva i codici dai server remoti e li salva temporaneamente nel cache:

$name = 'scg_' . md5 ($href);
if (false === ($value = get_transient ($name))) {
$response = wp_remote_get ($href);
if (!is_wp_error ($response)) {
$value = trim ($response['body']);
if (!empty ($value)) {
set_transient ($name, $value, 86400);
}
}
}

?>

Un secondo problema ha solo indirettamente a che fare con la Transients API. Le funzionalità della Options API usano le funzioni serialize() e unserialize(), cosa che diventa problematica con gli oggetti SimpleXML. Durante il test di myLCO me ne sono ricordato a mie spese.

Chi conosce queste piccole insidie ha però a disposizione un meccanismo molto robusto e veloce per il caching dei dati. Anche non usando la Transients API a questo punto è possibile capire cosa sono le righe in wp_options che hanno un prefisso _transient_. In ogni caso non dovrebbe essere un problema cancellarle. WordPress o il plugin responsabile eventualmente creano di nuovo i dati necessari.

Similar Posts: