La domanda che mi sono posto è stata: posso creare un’applicazione in PHP su Heroku che funzioni sia dentro sia fuori da Facebook? La risposta è sì e sto per dirvi anche come.

In questo articolo creerò una semplice applicazione per condividere dei link. Ogni utente può condividere un indirizzo web e assegnare un titolo e una descrizione. Ogni utente è identificato con il proprio indirizzo email (mantenuto privato) e se è autenticato all’interno di Facebook i suoi dati saranno recuperati dal profilo.

Creazione di un account Heroku

Tutto quello che serve per cominciare a lavorare con Heroku è creare un account. È una procedura che richiede 5 minuti di tempo e un’indirizzo email.

L’utilizzo base di Heroku è gratuito. Come riporta la documentazione “ogni applicazione ha accesso a 750 ore dyno al mese e a un database di 5Mb”. Un dyno è un singolo processo web che risponde alle richieste HTTP e le passa alla vostra applicazione.

Per utilizzare invece HTTPS dovete verificare il vostro account e fornire il numero di carta di credito. Ė necessario se volete che la vostra applicazione sia visibile quando Facebook utilizza la modalità sicura, ma se utilizzate il componente SSL di base sarà sempre gratuito.

Installazione degli strumenti di sviluppo

Il flusso di sviluppo di Heroku è interamente basato su Ruby e Git – la stessa console di Heroku altro non è che una gemma, e ogni volta che si esegue un comando git push l’applicazione è aggiornata in tempo reale. Quindi avremo bisogno di:

• installare Ruby (se usate OSX avete già la versione 1.8.x che è sufficiente);
• installare Git;
• installare la console Heroku (con il comando sudo gem install heroku o con l’installer ufficiale);
• impostare l’ambiente di lavoro con le credenziali di Heroku e la vostra chiave SSH.

Il modo migliore per fare tutte questo cose è seguire la guida rapida “Getting Started with Heroku”.

Per questo progetto è inoltre utile installare la gemma Taps che ci aiuterà ad esportare il nostro database.

MyLaptop:~ ragman$ sudo gems install taps

Creare l’applicazione

Il primo passo per creare l’applicazione è farlo sulla vostra macchina di sviluppo locale, poi si deve inizializzare il repository Git e successivamente si pubblica su Heroku.

Creazione dell’app in locale

Create una cartella vuota per l’applicazione e impostatela sul vostro web server.

MyLaptop:~ ragman$ cd /Users/Shared/WebServer/Sites
MyLaptop:Sites ragman$ mkdir HeroLinks

Create un nuovo sito sul vostro web server locale e fatelo puntare alla cartella appena creata con una URL del tipo http://herolinks.local.

Inizializzare il repository

Inizializzate un nuovo repository Git all’interno della stessa cartella.

MyLaptop:Sites ragman$ cd HeroLinks
MyLaptop:HeroLinks ragman$ git init
Initialized empty Git repository in .git/
MyLaptop:HeroLinks ragman$ cat
MyLaptop:HeroLinks ragman$ git add .
MyLaptop:HeroLinks ragman$ git commit -m "HeroLinks app created."

Trasferire l’applicazione su Heroku

Heroku imposta l’ambiente Ruby come impostazione predefinita per le nuove applicazioni. Per creare l’applicazione in PHP dobbiamo modificare gli argomenti della riga di comando per utilizzare lo stack chiamato Cedar.

Il comando da usare sarà simile a:

MyLaptop:HeroLinks ragman$ heroku create HeroLinks --stack cedar
Creating herolinks... done, stack is cedar
http://herolinks.herokuapp.com/ | git@heroku.com:herolinks.git
Git remote heroku added

Il comando crea l’applicazione sul server di Heroku e ci comunica il suo indirizzo pubblico e il percorso del repository remoto.

Il comando per pubblicare l’applicazione è:

MyLaptop:HeroLinks ragman$ git push heroku master

È necessario creare almeno un file nella cartella dell’applicazione o il comando fallisce, io ho creato un file index.php con un messaggio di benvenuto.

Il risultato del comando push sarà simile a:

Counting objects: 3, done.
Writing objects: 100% (3/3), 253 bytes, done.
Total 3 (delta 0), reused 0 (delta 0)
-----> Heroku receiving push
-----> PHP app detected
-----> Bundling Apache v2.2.19
-----> Bundling PHP v5.3.6
-----> Discovering process types
 Procfile declares types -> (none)
 Default types for PHP -> web
-----> Compiled slug size is 21.5MB
-----> Launching... done, v4
 http://herolinks.heroku.com deployed to Heroku
To git@heroku.com:herolinks.git
 * [new branch] master -> master

Cominciamo a programmare

Quest’articolo è focalizzato principalmente su Heroku e Facebook, pertanto non scriverò tutto il codice da zero ma utilizzerò alcuni componenti già pronti:

• Bootstrap – una libreria CSS creata dai ragazzi di Twitter (per definire lo stile dell’interfaccia);
• Slim – un framework PHP potente e leggero (per il controller principale);
• un paio di librerie estratte dal framework CakePHP (per la validazione dell’input);
• una semplice classe database creata da me che si appoggia a PDO.

Come si può notare dalla struttura della directory l’applicazione è piuttosto semplice.

Un file .htaccess indirizza tutte le richieste allo script `index.php` che contiene tutta la logica di controllo. La directory lib contiene le librerie esterne e la cartella templates contiene i file dell’interfaccia.

La nostra applicazione ha tre pagine: una home page che visualizza tutta la lista dei link condivisi (home.php), una pagina che contiene il form per condividere un nuovo link (new.php) e una pagina che visualizza i risultati della ricerca (search.php).

Accesso al database

La piattaforma Heroku crea uno spazio di 5MB sul database condiviso per tutte le applicazioni Ruby. Per le applicazioni PHP la creazione del database non è automatica, dobbiamo crearlo manualmente con il comando:

MyLaptop:HeroLinks ragman$ heroku addons:add shared-database

Le applicazioni possono accedere al database utilizzando la variabile d’ambiente DATABASE_URL che contiene la stringa di connessione. È accessibile da PHP come $_ENV["DATABASE_URL"].

Se acquistate un database dedicato come Heroku Postgres potete usare la console pgsql per amministrarlo. I database condivisi sono devono invece essere gestiti manualmente, ad eccezione dei comandi db:push e db:pull per l’importazione e l’esportazione dei dati.

Non ho installato PostgreSQL sulla mia macchina di sviluppo, quindi per la versione locale dell’applicazione ho utilizzato SQLite che punta a un file nella directory data. Il codice utilizzato per caricare il driver corretto è:

// if $_ENV["DATABASE_URL"] is empty then the app is not running on Heroku
if (empty($_ENV["DATABASE_URL"])) {
    $config["db"]["driver"] = "sqlite";
    $config["db"]["url"] = "sqlite://" . realpath("data/my.db");
}
else {
    // translate the database URL to a PDO-friendly DSN
    $url = parse_url($_ENV["DATABASE_URL"]);
    $config["db"]["driver"] = $url["scheme"];
    $config["db"]["url"] = sprintf(
        "pgsql:user=%s;password=%s;host=%s;dbname=%s",
         $url["user"], $url["pass"], $url["host"],
         trim($url["path"], "/"));
}

Come prima cosa imposto il database di default a SQLite, se la variabile $_ENV["DATABASE_URL"] non è impostata vuol dire che sto utilizzando l’ambiente locale. Se invece sono su Heroku devo elaborare la stringa di connessione e convertirla in un formato compatibile con PDO. La stringa di partenza é simile a:

postgres://username:password@host/database

e deve essere convertita nel formato

pgsql:user=username;password=password;host=host;dbname=database

Il controller principale

Il file index.php è il controller principale dell’applicazione. Dopo aver impostato il database si passa a configurare i dettagli di Facebook, poi si caricano le altre librerie e si crea un nuovo oggetto della classe Slim che è la nostra applicazione.

// Load the core Slim framework...
require_once "lib/Slim/Slim.php";

// ...add other accessory libraries
require_once "lib/db/db.class.php";
require_once "lib/cake/sanitize.php";
require_once "lib/cake/validation.php";

// and then the Facebook SDK
require_once "lib/facebook/facebook.php";

// Create a new Slim application
$app = new Slim();

In questo caso sto creando l’oggetto Slim con le impostazioni di default, è possibile passare al costruttore un array associativo di parametri, ma per il momento i default ci vanno bene.

Utilizziamo Slim per collegare le URL dell’applicazione ad altrettante funzioni PHP. Abbiamo 4 URL: / (la home), /new, /search e /install.

Slim consente di mappare ad una URL funzioni diverse per gestire i diversi metodi HTTP oppure una funzione sola che gestisce più di un metodo. In questo caso abbiamo bisogno che la funzione collegata alla URL principale gestisca i metodi GET e POST, perché quando l’applicazione sarà chiamata da Facebook riceverà dei dati via POST, la famosa signed request. Il codice che ci serve è:

$app->map("/", function () use ($app, $config) {
            // do something
    })->via("GET", "POST");

Il metodo map() fa proprio questo, collega una funzione anonima all’URL principale e specificando che deve essere accessibile se il metodo HTTP utilizzato è GET o POST.

Installazione dell’applicazione

Normalmente cercherei di scrivere un codice di installazione che funzioni in qualsiasi ambiente, ma ci sono delle differenze tra SQLite e PostgreSQL che vanno oltre il raggio d’azione di questo articolo. Per ovviare a queste differenze l’installer è abilitato solo sulla copia locale dell’applicazione, per copiare i dati in remoto utilizzeremo le funzioni di Heroku.

La funzione anonima associate all’URL /install esegue un controllo sulla variabile $config per determinare l’ambiente di esecuzione. Se l’ambiente utilizza il driver SQLite vengono eseguite delle query che creano le tabelle necessarie utilizzando lo standard PDO.

$app->get("/install", function() use ($app) {
    global $config;
    // check driver and perform install only for SQLite/local
    if ($config["db"]["driver"] == "sqlite") {
        if ($db = Db::getConnection()) {
            $query = "CREATE TABLE IF NOT EXISTS links (
                id INTEGER PRIMARY KEY,
                url VARCHAR(255),
                title VARCHAR (100),
                description VARCHAR(512),
                username VARCHAR(50),
                useremail VARCHAR(100),
                created DATE DEFAULT (datetime('now','localtime'))
            )";
            try {
                $stmt = $db->prepare($query);
                $stmt->execute();
                $app->flash("info", "Application installed successfully!");
                $app->redirect("/");
            }
            catch (PDOException $e) {
                $app->flashNow("error", "Unable to install application: " .
                    $e->getMessage());
            }
        }
        else {
            $app->flashNow("error", "Unable to open DB");
        }
    }
    else {
        $app->flashNow("info", "Install command is for local/SQLite only, try to run <code>heroku db:push sqlite://data/my.db</code> instead!");
    }
    $app->render("default.php", array("action" => "install"));
});

La variabile $db è un oggetto PDO, il metodo statico Db::getConnection() cerca di connettersi al database o restituisce NULL in caso di errore.

Il metodo flash() salva un messaggio testuale nella sessione corrente associato ad un’etichetta “info”. Il messaggio è poi disponibile nella successiva richiesta HTTP (la pagina successiva). Esiste anche un metodo flashNow(); il messaggio salvato da questo metodo è accessibile nella pagina corrente all’interno della variabile $flash.

Utilizzando delle parole chiave appropriate (error, info, warning, ecc) è possibile fare in modo che il messaggio sia associato agli stili CSS predefiniti da Bootstrap, per esempio:

<?php
if (!empty($flash["error"])) {
?>
<div class="alert-message error">
 <?php echo $flash["error"] ?>
</div>
<?php
}?>

Il metodo render() accetta due parametri:

• il file PHP (o HTML) che contiene l’interfaccia,
• un array associativo di variabili che sono passati al file chiamato.

In questo caso è passata una variabile chiamata action che contiene il valore “install”; Il file default.php avrà una variabile corrispondente chiamata $action da utilizzare. I file di interfaccia sono contenuti nella directory templates ma questo valore è personalizzabile utilizzando la configurazione di Slim (vi rimando al manuale per maggiori informazioni). Una volta installato il database in locale si possono usare i comandi di Heroku per importare la struttura (e i dati se ci sono) nell’applicazione remota.

MyLaptop:HeroLinks ragman$ heroku db:push sqlite://data/my.db

Il risultato del comando dovrebbe assomigliare a:

Loaded Taps v0.3.23
     Warning: Data in the app 'herolinks' will be overwritten and will not be recoverable.
     !    WARNING: Potentially Destructive Action
     !    This command will affect the app: herolinks
     !    To proceed, type "herolinks" or re-run this command with --confirm herolinks

Bisogna digitare il nome dell’applicazione e premere invio per confermare l’importazione.

Il flusso dell’applicazione

Il resto dell’applicazione è lineare e segue il metodo di programmazione simile a Model-View-Controller, con la differenza che in questo caso non abbiamo un Model.

La homepage recupera i 10 link più recenti dal database utilizzando una query SQL. I risultati sono salvati in un array $links e passati al file di interfaccia (home.php) dal metodo render().

<?php
$app->map("/", function () use ($app) {
    $pageTitle = "Latest Links";
    $action = "home";
    $links = array();
    if ($db = Db::getConnection()) {
        $query = "SELECT * FROM links ORDER BY created DESC LIMIT 10";
        try {
            foreach ($db->query($query) as $link) {
                $links[] = $link;
            }
        }
        catch (PDOException $e) {
            $app->flashNow("error", $e->getMessage());
        }
    }
    else {
        $app->flashNow("error", "Unable to open DB");
    }
    $app->render("home.php", array(
        "pageTitle" => $pageTitle,
        "action" => $action,
        "links" => $links));
})->via("GET", "POST");

<?php
if (!empty($links)) {
?>
<h2>Latest links</h2>
<table class="linklist zebra-striped" summary="Latest submitted links">
 <tr>
  <th>Site</th>
  <th>Description</th>
  <th>User</th>
  <th>Date</th>
 </tr>
<?php
    foreach($links as $link){
?>
 <tr>
  <td><a href="<?php echo $link["url"] ?>" rel="external"><?php echo $link["title"] ?></a></td>
  <td><?php echo $link["description"] ?></td>
  <td><?php echo $link["username"] ?></td>
  <td><?php echo date("d F Y H:i", strtotime($link["created"])) ?></td>
 </tr>
<?php
    }
?>
</table>
<?php
}
else {
?>
<div class="alert-message block-message info">
 <p>Sorry, the link database is empty!</p>
 <div class="alert-actions"><a class="btn primary" href="/new" >Add a link now</a></div>
</div>
<?php
}

La pagina che aggiunge un nuovo link recupera i dati del form con i metodi request()->isPost() e request()->post() di Slim. I dati sono poi ripuliti e convalidati con i metodi delle classi Sanitize e Validation del framework CakePHP.

$app->map("/new", function () use ($app) {
        $pageTitle = "Add new link";
        $action = "new";
        $data = array();
        $errors = array();
        if ($app->request()->isPost()) {
            $data = $app->request()->post();
            $data = Sanitize::clean($data, array("escape" => false));
            $valid = Validation::getInstance();
            if (!$valid->email($data["useremail"])) {
                $errors["useremail"] = "Invalid email address";
            }
            if (!$valid->notEmpty($data["username"])) {
                $errors["username"] = "Please insert your name";
            }
            if (!$valid->notEmpty($data["title"])) {
                $errors["title"] = "Please insert a title";
            }
            if (!$valid->url($data["url"])) {
                $errors["url"] = "Invalid or empty URL";
            }
            if (empty($errors)) {
                if ($db = Db::getConnection()) {
                    $query = "INSERT INTO links (url, title, description, username, useremail) VALUES(:url, :title, :description, :username, :useremail)";
                    try {
                        $stmt = $db->prepare($query);
                        $stmt->bindParam(":url", $data["url"]);
                        $stmt->bindParam(":title", $data["title"]);
                        $stmt->bindParam(":description", $data["description"]);
                        $stmt->bindParam(":username", $data["username"]);
                        $stmt->bindParam(":useremail", $data["useremail"]);
                        $stmt->execute();
                        $app->flash("info", "Link added successfully!");
                        $app->redirect("/");
                    }
                    catch (PDOException $e) {
                        $app->flashNow("error", "Unable to save your URL: " . $e->getMessage());
                    }
                }
                else {
                    $app->flashNow("error", "Unable to open DB");
                }
            }
        }
        $app->render("new.php", array(
            "pageTitle" => $pageTitle,
            "action" => $action,
            "data" => $data,
            "errors" => $errors));
    })->via("GET", "POST");

Eventuali errori sono salvati nell’array $errors che è utilizzato sia dal controller che dalle view (i file di interfaccia). Il controller utilizza $errors per determinare se i dati possono essere salvati nel database e la view per visualizzare i messaggi di errore nei relativi campi del form.

<form action="" method="post" accept-charset="utf-8">
 <fieldset>
  <div class="clearfix<?php if (!empty($errors["url"])) echo " error" ?>">
   <label for="url">Site URL</label>
   <div class="input">
    <input type="text" size="30" name="url" id="url" class="xlarge" value="<?php echo (!empty($data["url"])) ? $data["url"] : ""; ?>">
<?php
$field = "url";
if (!empty($errors[$field])) {
?>
    <span class="help-inline"><?php echo $errors[$field] ?></span>
<?php
}
?>
   </div>
  </div>
  <!-- Other fields here -->
 </fieldset>
</form>

Per salvare i dati nel database ho utilizzato istruzioni PDO all’interno di un blocco try-catch. Il metodo flashNow() visualizza eventuali errori PDO (ovviamente questo va evitato se siamo in un ambiente di produzione).

La pagina di ricerca è quasi identica alla homepage, ad eccezione del fatto che prima di eseguire la query viene valutato il termine di ricerca.

$app->get("/search(/:key)", function($key = null) use ($app) {
        $pageTitle = "Link Search";
        $action = "search";
        $links = array();
        if ($app->request()->isGet()) {
            if (empty($key)) {
                $key = $app->request()->get("key");
            }
            $key = Sanitize::clean($key, array("escape" => false));
        }
        if ($db = Db::getConnection()) {
            $query = "SELECT * FROM links WHERE (title LIKE :key OR url LIKE :key) ORDER BY created DESC";
            try {
                $stmt = $db->prepare($query);
                $needle = "%" . $key . "%";
                $stmt->bindParam(":key", $needle, PDO::PARAM_STR);
                $stmt->execute();
                while ($link = $stmt->fetch(PDO::FETCH_ASSOC)) {
                    $links[] = $link;
                }
            }
            catch (PDOException $e) {
                $app->flashNow("error", "Unable to execut search: " . $e->getMessage());
            }
        }
        else {
            $app->flashNow("error", "Unable to open DB");
        }
        $app->render("search.php", array(
            "pageTitle" => $pageTitle,
            "action" => $action,
            "key" => $key,
            "links" => $links));
    });

La sintassi $app->get("/search(/:key)", function($key = null) significa che ogni stringa che segue il nome dell’azione /search è considerata termine di ricerca e salvata nel parametro $key della funzione associata. La variabile è poi “ripulita” prima dell’uso.

Il collegamento a Facebook

Fino a qui l’applicazione funziona bene da sola. Per essere utilizzata dentro Facebook e recuperare i dati dell’utente abbiamo bisogno di:

• scaricare il Facebook PHP SDK da GitHub,
• registrare l’applicazione su Facebook a partire dalla pagina sviluppatori.

Ho copiato la directory src del SDK nella directory lib dell’applicazione e l’ho rinominata facebook.

Per registrare l’applicazione si Facebook bisogna fornire una serie di dettagli come l’indirizzo dell’applicazione (es http://myapp.heroku.com) e il nome utilizzato per il componente (canvas) che ospiterà l’applicazione all’interno di Facebook. Se scelgo per esempio “myapp” sarà creato un indirizzo https://apps.facebook.com/myapp/ per l’applicazione.

Una volta registrata l’applicazione possiamo provvedere a impostare i dettagli di configurazione nel nostro controller `index.php`.

$config["facebook"]["appId"] = "YOUR_APP_ID";
$config["facebook"]["secret"] = "YOUR_APP_SECRET";
$config["facebook"]["canvas"] = "your-app-canvas";
$config["facebook"]["canvas_url"] = "https://apps.facebook.com/your-app-canvas/";

Ci serve anche un altro parametro che è l’indirizzo della nostra applicazione e deve essere fornito alla funzione di autorizzazione.

$config["app"]["home"] = "https://your-app.heroku.com";

L’integrazione con Facebook avviene in due sezioni distinte del codice. Nella prima sezione viene creato un nuovo oggetto della classe Facebook e viene assegnato come proprietà dell’oggetto $app che è la nostra applicazione. Il vantaggio di questa soluzione è che se è possibile accedere all’applicazione è anche possibile accedere al collegamento con Facebook. In questa sezione impostiamo anche la proprietà facebookCanvas che serve all’applicazione per capire se si trova all’interno di Facebook oppure no.

$app = new Slim();
$app->Facebook = new Facebook($config["facebook"]);
$app->facebookUserProfile = null;
$app->facebookCanvas = isRunningInsideFacebook();

Il secondo punto di integrazione è la funzione isRunningInsideFacebook() che si occupa di determinare se l’applicazione è eseguita all’interno di Facebook; per fare questo controlla la presenza della variabile cifrata signed_request passata da Facebook via POST.

function isRunningInsideFacebook() {
    return !empty($_REQUEST["signed_request"]);
}

La funzione facebookInit() si occupa di tutto il resto, come controllare di avere i permessi di accesso. Utilizzando le funzioni del SDK estrae i dati ricevuti, se non esiste un parametro user_id l’applicazione non è autorizzata quindi deve ridirigere l’utente verso Facebook per richiedere l’autorizzazione.

function facebookInit() {
        global $app;
        global $config;
        if ($fbData = $app->Facebook->getSignedRequest()) {
            // redirect to Facebook Authorization if the User ID is not in the request
            if (empty($fbData["user_id"])) {
                $auth_url = "https://www.facebook.com/dialog/oauth?client_id="
                          . $config["facebook"]["appId"] . "&redirect_uri=" . urlencode($config["app"]["home"])
                          . "&scope=email";
                echo '<script type="text/javascript">// <![CDATA[
               top.location.href = "' . $auth_url . '";
// ]]></script>';
                exit;
            }
        }
        if ($fbAccessToken = $app->Facebook->getAccessToken()) {
            // if code is present it was sent by an auth request, so redirect back to Facebook App Page
            if ($code = $app->request()->get("code")) {
                $app->redirect($config['facebook']["canvas_url"]);
            }
            $user = $app->Facebook->getUser();
            if ($user) {
                try {
                    // proceed knowing you have a logged-in user who is authenticated
                    $app->facebookUserProfile = $app->Facebook->api("/me");
                    $app->facebookUserProfile["logout"] = $app->Facebook->getLogoutUrl();
                }
                catch (FacebookApiException $e) {
                    $app->flashNow("error", $e->getMessage());
                    $user = null;
                }
            }
        }
    }

Se l’applicazione è autorizzata riceve un parametro chiamato code che è la chiave d’accesso temporanea fornita dal servizio OAuth di Facebook. Il servizio reindirizza l’utente all’indirizzo esterno dell’applicazione e il ho scelto di far tornare l’utente alla versione “dentro Facebook”. Se l’autorizzazione è negata i parametri ricevuti sono differenti, ma per questo articolo sono consapevolmente ignorati.

Il codice quindi recupera i dati dal profilo dell’utente e li salva nella proprietà $app->facebookUserProfile.

Ma quando viene eseguito questo codice? Il codice che associa le funzioni PHP collegate alle varie azioni è stato leggermente modificato in:

$app->map("/", "facebookInit", function () use ($app, $config) {
        // other code here
    })->via("GET", "POST");

Nella terminologia di Slim si chiama Middleware. La funzione facebookInit() è chiamata prima di elaborare la URL. Questa funzionalità ci garantisce che ogni pagina ha accesso ai dati di Facebook.

Conclusioni

Questo esempio ci mostra cosa possiamo ottenere con Heroku, Facebook e altri componenti gratuiti. Spero che vi sia venuta voglia di approfondire l’argomento e di creare la vostra prossima applicazione con Heroku. Troverete il codice sorgente a partire da questo link. Happy coding!

Diciamo che abbiamo bisogno di importare o esportare dei dati da un file di backup molto grande, di circa 50.000 articoli e 200.000 categorie e tag, e che ogni oggetto debba essere a sua volta elaborato (es. ripulitura del codice, scaricamento delle immagini, ecc).

Con uno script web possiamo facilmente andare incontro ad alcuni tipici problemi:

• l'esecuzione dello script dura troppo a lungo e viene terminata dal server
• lo script necessita di più memoria di quella fornita dal server

Se il vostro problema è di questo tipo, può essere risolto agilmente con uno script a linea di comando. Inoltre, sempre se il vostro fornitore lo consente, potete impostare un vero script di cron anzichè affidarvi alla funzione pseudo-cron di WordPress per gestire gli eventi temporizzati. Ma cominciamo a vedere un po' di codice.

Passo 1 - Impostiamo il nostro ambiente

La prima cosa da fare è creare un ambiente in cui possiamo eseguire i nostri script. Una soluzione possibile è la creazione di una directory wp-content/bin in cui ospitare tutti i nostri script.

Il primo e più importante file che andiamo a creare è chiamato cli.php, contiene il codice comune a tutti gli script (una sola istruzione per il momento) e deve assolutamente essere incluso in tutti gli script, vediamo perché:

if ('cli' != php_sapi_name()) exit("Not this way babe!\n");

Questa istruzione dice al nostro interprete PHP che lo script deve essere eseguito solo ed esclusivamente se lo stiamo chiamando da una console. È possibile aggiungere altre funzioni comuni a questa libreria, ma per il momento questa è la più importante. Ora andiamo a scrivere il nostro primo script che si chiamerà test-posts.php e recupererà la lista degli articoli più recenti.

Passo 2 - Impostazioni di sicurezza

Non è un passo obbligatorio, ma caldamente raccomandato: possiamo impostare il nostro script in modo che possa essere eseguito solo da alcuni utenti e inoltre possiamo anche impostare una password da passare alla riga di comando.

Importante: Assicuratevi che i permessi di accesso ai vostri script siano impostati in modo da impedire l'accesso e l'esecuzione ad utenti non autorizzati. Questo dipende da come è impostato il vostro sistema, ma in generale impostando i permessi a 600 potrà essere eseguito solo dal proprietario con il comando

$ php -f test-posts.php

Quindi con queste righe di codice possiamo impostare una restrizione a livello utente.

$users = array('someuser', 'anotheruser');
$cli_user = exec('whoami');
if (!empty($users)) {
    if (!in_array($cli_user, $users)) {
        echo "Your username ({$cli_user}) is not in my list babe!\n";
        exit(1);
    } // end if
} // end if

Poi potremmo voler richiedere il passaggio di una chiave segreta alla riga di comando, per esempio:

$ php -f test-posts.php -- --key=SuperSecretKey

Possiamo ottenere questo con queste istruzioni:

if (!defined('CLI_SECRET')) define('CLI_SECRET', 'SuperSecretKey');
if (CLI_SECRET !== '') {

    // Check for arguments
    if ($argc < 2) {
        echo "Invalid arguments: a super secret code is needed to run this script!\n";
        printf("Usage: /path/to/php -f %s -- --key=<supersecret>\n", basename(__FILE__));
        exit(2);
    } // end if

    // Parsing arguments: move the secret key (if present) to $_GET['key'] var.
    $args = split('=', $argv[1]);
    if ('--key' == $args[0]) $_GET['key'] = $args[1];

        // Do stuff
        if(CLI_SECRET !== $_GET["key"]){

        echo "Access denied!\n";
        exit(3);

    } // end if

} // end if

Passo 3 - Carichiamo WordPress

Ora possiamo caricare l'ambiente di WordPress all'interno del nostro script e con il prossimo passo andremo invece a scrivere il nostro codice personalizzato.

Dobbiamo tenere conto che alcuni plugin potrebbero interferire con questa fase, in particolare quei plugin che fanno uso di cookie o intestazioni HTTP potrebbero lamentarsi se visualizziamo qualcosa a video prima che il caricamento di WordPress sia terminato.

Con la prossima istruzione ci assicuriamo innanzitutto che i plugin di gestione della cache tipo WPSuperCache vengano disattivati.

$_POST['wp_cache_status'] = 'none';

Poi includiamo i file necessari per il caricamento di WordPress (il percorso esatto dipende da dove si trovano i file nella vostra installazione).

$wpLoader = realpath(dirname(__FILE__) . '/../../wp-load.php');
require_once($wpLoader);

A questo punto se non ci sono errori possiamo accedere ai dati di WordPress.

Passo 4 - Accesso e gestione dei dati

Giunti a questa fase possiamo utilizzare tutte le API fornite da WordPress e dai plugin correntemente attivati. Il codice di esempio qui di seguito recupera l'elenco dei post più recenti:

$posts = get_posts();
foreach ($posts as $post) {
    setup_postdata($post);
    echo " - ";
    the_title();
    echo "\n";
} // end foreach

Possiamo eseguire lo script con il comando:

php -f test-posts.php -- --key=SuperSecretKey

E l'output sarà simile a:

WordPress successfully loaded!

 - Lorem ipsum dolor sit amet
 - Consectetur adipisicing elit
 - Duis aute irure dolor in reprehenderit
 - ...
 - Last post of the list

Un buon punto di partenza

Utilizzando questo esempio come un template, possiamo fare più o meno tutto quello che vogliamo sul nostro blog. Il limite è come sempre la nostra fantasia.

Vi invito quindi a scaricare il codice sorgente degli script e a postare nei commenti le vostre opinioni, domande e suggerimenti.

Gli eBook sono enormemente comodi, sia per i manuali tecnici, di cui mi piace la formula “digital bundle” (PDF + ePub + mobi), sia per i libri classici, quelli da leggere in poltrona o sui treni, che sono sempre più pieni e tirar fuori un libro da leggere è un’impresa.

Però mi piace anche l’ambiente libreria, per la sua atmosfera particolare, un’esperienza molto più bella anche rispetto al miglior negozio di libri virtuale. Allora come si fa a mettere insieme le due cose?

Qui di seguito c’è un’idea che mi è venuta, sotto forma di storiella, magari qualcuno interessato la vede e ci lavora sopra…

Allora, entro in libreria (Mondadori, Feltrinelli, Giunti o “quella Sottocasa”) e lungo le pareti vedo gli scaffali di libri (di carta) e i poster con le copertine dei nuovi arrivi. In posizione di evidenza ci sono i tavoli con i nuovi arrivi o le offerte speciali (più o meno come ora).

In un angolo c’è un salottino per poter leggere i libri comprati, o sfogliare i cataloghi o alcune riviste. Di fianco alle poltrone del salottino cosa c’è?

La parte “e”: diversi tablet (iPad, Kindle, ecc) a disposizione della clientela, adeguatamente “agganciati alla seggiola”. I clienti, seduti in poltrona, li utilizzano per sfogliare i cataloghi elettronici di libri e riviste, leggere le anteprime, le recensioni, oppure l’ultimo numero di Wired. Ma come si compra?

Alternati ai tavoli con le novità ci sono delle “torrette”, come quelle dei negozi di CD, tutte colorate con le copertine dei libri in uscita. Le torrette sono quadrate e su ogni lato c’è agganciato un tablet che fa girare l’applicazione catalogo della libreria in questione.

Io sono attirato dalla copertina di un libro cartaceo, il nuovo di “scegliete voi chi”. Guardo la copertina, leggo il riassunto, mi piace, e noto che è disponibile anche in formato elettronico.

Vado alla torretta con l’iPad, cerco il libro nel catalogo, ne vedo altri, che mi piacciono, leggo le trame e li aggiungo al carrello elettronico. Quando ho finito stampo il mio carrello su un foglietto, tipo scontrino con un codice a barre e l’elenco dei libri richiesti, non ho ancora pagato niente.

Nota: si potrebbe essere ancora più “eco-friendly” se al posto dello scontrino ritiro una tessera di plastica con un codice a barre, come quelle dei parcheggi ATM di Milano, per esempio.

Vado alla cassa, porgo lo scontrino del carrello, la commessa passa il codice a barre, pago in contanti (per gli amanti della privacy estrema) o con il bancomat e cosa ottengo?

Vediamo, la consegna potrebbe avvenire:

• via email: lascio l’indirizzo email alla commessa e mi arriva un’email che contiene il link per scaricare i miei acquisti, oppure
• porgo alla commessa la mia chiave USB e lei procede a caricare i libri, oppure
• direttamente con il mio tablet personale mi collego alla rete wireless del negozio, inserisco il codice dello scontrino e scarico i libri sul mio lettore, quindi vado al salottino per leggere…
• …oppure mi collego da casa al sito della libreria, inserisco lo stesso codice e scarico.

Cosa vi sembra, può funzionare? Certo ci sono un po’ di dettagli tecnici da sistemare, la sicurezza delle chiavi USB, della rete wireless, però sembra una cosa praticabile.

Unisce la praticità degli eBook con l’esperienza della libreria classica con salottino di lettura. Voi cosa ne pensate? Ne avete già viste?

Passo 1: il concept

Definire il concept del mio logo non è stato per niente semplice, perché avrebbe dovuto rappresentare le mie diverse personalità: designer, sviluppatore, musicista, compositore e professionista. Volevo qualcosa che apparisse al tempo stesso professionale, ma altrettanto fresco.

Poi volevo che il logo includesse anche un simbolo, icona, glifo che potesse essere utilizzato indipendentemente. Infine avrebbe dovuto rendere bene sia nella versione al tratto che in quella con colori ed “effetti speciali”.

Passo 2: la ricerca dei simboli

Sarà il mio passato come Master di Dungeons & Dragons oppure la passione per il fantasy e i misteri, sta di fatto che mi piacciono le rune. Quindi ho fatto una ricerca su alcuni testi per trovare dei simboli runici da usare come punto di partenza. Ne ho trovato uno chiamato Jera, nella sua forma originale così come appare nell’antico alfabeto chiamato Elder Futhark.

Alcuni dei significati di questa runa sono: raccolto, azione buona, comunità, energia. Nell’antica arte della divinazione runica, la runa Jera parlava di armonia e cambiamento. Curiosamente in quel periodo di cambiamenti nella mia vita ce ne sono stati parecchi. Infine il colore associato a Jera è il blu, che è anche il mio colore preferito.

Ho fatto qualche esperimento di trasformazione con carta e matita e anche con Illustrator, ma alla fine la runa originale mi piaceva di più e l’ho trovata rappresentata degnamente nel font open source Junicode.

Passo 3: il giusto carattere

Prima di andare a guardare le solite librerie tipo Adobe o Linotype ho preso l’abitudine di cercare ispirazione in dafont.com. Ho trovato 20-30 caratteri interessanti e ho cominciato a giocare con Illustrator.

Ho quindi ridotto i candidati a quattro o cinque e chiesto un parere ad alcuni amici, il verdetto è stato… Baar Sophia di Lutz Baar e Petita di Manfred Klein. Sono due font gratuiti per uso personale, mentre per altri utilizzi gli autori chiedono che sia fatta una donazione ad un ente non-profit come Medici Senza frontiere, fatto.

Passo 4: disegnare il logo – ne resterà solo uno

Ho cominciato qualche ciclo di disegna-pausa-rivedi e anche in questo caso ho prodotto i soliti quattro o cinque candidati. Li ho fatti vedere ai soliti amici e, sorpresa! Eravamo tutti attratti dallo stesso. Aggiudicato!

Passo 5: la scelta dei colori

Avevo già deciso di utilizzare una tonalità di blu come colore principale ma non volevo che sembrasse troppo “corporate”. Ho ripescato una foto fatta diversi anni fa con dei blu interessanti, ne ho campionati un po’ e ho sperimentato diverse varianti con l’applicazione myPantone e la guida colore Pantone Goe™ fino a che non ho trovato quello giusto. E poi?

In quel periodo stavo leggendo Designing for the Web di Mark Boulton e ho trovato un suggerimento sull’accoppiata blu e lime… perché no? Ho trovato una tonalità interessante di lime sulla guida colore e ho aggiunto un candidato all’elenco dei loghi, che alla fine è diventato il mio preferito. Avevo trovato il mio logo!

Ultimo passo: guida all’uso

Avevo un logo, dei colori “ufficiali” per il mio brand personale, perché non mettere tutto insieme in una bella mini-guida? Fatta, stampata e messa bene in vista a disposizione come riferimento per gli usi futuri.

Ho imparato qualcosa: usare i plugin!

Quando ho pubblicato il sito, anni fa, WordPress era alla versione 1.5 e non era così facilmente integrabile alle mie necessità, principalmente il supporto bilingue e qualche altra cosina. Io però ero più giovane, avevo molto più tempo libero, quindi ho integrato quello che mi serviva direttamente nei sorgenti, grosso errore!

Anche a tenere traccia delle modifiche, dopo qualche tempo gestire gli aggiornamenti è diventato pesante, con due effetti particolarmente negativi:

• non riuscire ad utilizzare le novità delle nuove versioni di WordPress,
• avere un sito potenzialmente bucabile dal primo sfigato di passaggio.

Ho quindi preferito chiuderlo per un po’ e concentrarmi sui social network; nel frattempo avrei fatto tesoro dell’esperienza accumulata lavorando sul WordPress di altri con necessità più umane. E anche aspettando una versione più matura di WordPress…

…ed eccomi di nuovo qui

Ho imparato la lezione e ho costruito un sito intorno ad un “theme framework” (parola sconosciuta fino a qualche anno fa) risultato delle buone abitudini acquisite in questi anni. Compreso nel pacchetto c’è un plugin di “addons” personalizzati e un nuovo campo di battaglia dove sperimentare. Buon giorno a tutti!

Recentemente però un cliente lo ha richiesto espressamente per un CMS fatto su misura, quindi ho dovuto cercarne uno che girasse bene in accoppiata con jQuery/jQuery UI.

Ho trovato WYMEditor: veloce, facile da installare, facile da usare e facile da personalizzare. Per ora è la mia scelta, voi cosa ne pensate?

Il Garante della privacy ha da poco pubblicato la sua guida per la tutela dei dati sui social network.

Personalmente sono soddisfatto di come è stata impostata e realizzata. Consiglio a tutti la lettura dell’opuscolo che potete scaricare dal sito ufficiale.

Buona lettura!

La cosa ha fatto preoccupare i garanti della privacy di tutto il mondo che hanno pensato di prendere dei provvedimenti. Tremo al solo pensiero di cosa possa uscire dal loro cilindro…

In realtà  la tecnologia definitiva per difendere i fatti nostri ce l’abbiamo “built-in” fin dalla nascita (tanto per citare S.J.) e si chiama cervello.

È un hardware molto evoluto e può essere esteso e aggiornato con diversi plugin, primo fra tutti il buon senso.

Il buon senso dovrebbe dirci quando vale la pena condividere certe informazioni e quando invece farne a meno. In generale ci sono casi in cui è soggettivo, altri in cui drizzare le antenne e riflettere sulle possibili conseguenze.

Per esempio: pago un servizio aggiuntivo al mio provider per non pubblicare il mio indirizzo di casa sui record di registrazione dei miei domini. Perché quindi dovrei comunicarlo ad un pinco pallino qualunque che mi promette un fantastico eBook gratuito su come aumentare i visitatori del mio blog? O una suoneria per cellulare, uno sfondo per il computer o qualche altra cosa che magari posso reperire con 10 minuti di Google senza comunicare niente a nessuno?

Già quando sono obbligato a fornire l’indirizzo email per scaricare qualcosa mi girano. Se mi interessano le informazioni che puoi darmi te lo do io spontaneamente.

Dal nostro lato di utenti dovemmo essere più selettivi e attenti a come gestiamo la nostra vita online. Nella vita reale i foglietti si possono stracciare e le cose dette si possono dimenticare, ma sul web rimangono.

Non è necessario rinunciare a tutto, ma addestrare il buon senso e sviluppare delle buone abitudini che ci aiutino a vivere meglio. Come ad esempio chiedere il permesso prima di pubblicare la foto di qualcuno o evitare di pubblicare foto e filmati che ritraggono noi o i nostri amici in situazioni “discutibili”.

Non è escluso che il nostro capufficio o un nostro cliente o potenziale cliente possano “casualmente” venirne in possesso…

Nel caso particolare di Facebook sicuramente possono esserci delle questioni tecniche alla base della mancata eliminazione di alcuni dati degli utenti, d’altra parte il sito e i servizi si sono evoluti molto velocemente ed è normale che ci sia qualche bug e confido che ci metteranno una pezza il più presto possibile.

Dal lato dei garanti credo che sia meglio puntare sull’educazione invece che sulla repressione. E soprattutto controllare che chi gestisce i dati rispetti le leggi in materia e non ne faccia un uso troppo “disinvolto”.

Diciamoci la verità , se c’è qualche programmatore in ascolto: possibile che non vi sia mai capitato di sviluppare un’applicazione che raccoglie dati dagli utenti per un servizio qualsiasi e di leggere nelle specifiche che i dati degli utenti che si disiscrivono al servizio XYZ non vanno cancellati ma vanno solamente segnalati come inattivi perchè potrebbero sempre servire in futuro? E per cosa se non hai il permesso di usarli?

Se ne potrebbe parlare molto più a lungo, ma la chiudo qui. Quel che volevo dire è che ci si può iscrivere a tutti i social network, chat, community & c della rete, basta avere voglia e tempo. Il bello della rete e che puoi trovare e fare veramente di tutto, ma con un cervello funzionante e attento ti diverti di più…

Situazione iniziale

Obiettivo: cancellare da un’installazione di WordPress 2.6.3 tutti i post appartenenti alla categoria ‘Musica’ o ad una delle sue sotto-categorie.

Problema: il pannello di amministrazione causa diversi errori anche dopo avere disabilitato tutti i plugin, ma non c’è il tempo necessario per andare a caccia della causa.

Nota: i parametri relativi all’installazione specifica di WordPress non sono quelli esposti in questo esempio. Per comodità  assumerò ‘Musica’ come categoria base, al cui ID nel database assegno il valore arbitrario “100”, utilizzando il prefisso di default “wp_” per le tabelle del database.

Premessa tecnica: gestione delle tassonomie in WordPress

WordPress gestisce le categorie e i tag utilizzando 3 tabelle:

wp_terms

Contiene i nomi di categorie e tag tutti insieme.

wp_term_taxonomy

Contiene i dettagli sui termini, cioè se un termine è un nome di categoria
(category), un tag applicato a un post (post_tag), una categoria di link
(link_category), ecc e il collegamento con il suo genitore (parent).
Il campo term_taxonomy_id è la chiave primaria della tabella ed è usato come chiave esterna nella tabella wp_term_relationships.

wp_term_relationships

Contiene le relazioni tra i termini (term_taxonomy_id) e gli oggetti associati (object_id), post o link.

Passo 1: troviamo tutti i termini collegati alla categoria madre

Nella tabella wp_terms il termine “Musica” ha term_id=100. Per avere una lista dei termini associati la query da eseguire è:

[code lang="sql" light="true"]SELECT * FROM wp_term_taxonomy WHERE term_id = 100 OR parent = 100[/code]

Per utilizzarla nel passo successivo però ci serve solo la chiave, quindi eseguiremo:

[code lang="sql" light="true"]SELECT term_taxonomy_id FROM wp_term_taxonomy WHERE term_id =100 OR parent =100[/code]

Passo 2: selezioniamo gli ID dei post che ci interessano

Il campo che collega le tabelle wp_term_relationships e wp_term_taxonomy è term_taxonomy_id, quindi ho usato 2 query annidate per avere tutti i dati in un passaggio solo:

SELECT object_id
FROM <code>wp_term_relationships</code>
WHERE <code>term_taxonomy_id</code>
IN (

	SELECT term_taxonomy_id
	FROM <code>wp_term_taxonomy</code>
	WHERE term_id =100
	OR parent =100
)

Questa query recupera gli ID di tutti i post appartenenti alle categorie interessate e sarà  utilizzata nel prossimo passo.

Passo 3: applichiamo il risultato

Per selezionare i post che mi interessano interrogo la tabella wp_posts inserendo le due query ricavate in precedenza nella condizione WHERE.

SELECT *
FROM wp_posts
WHERE ID
IN (

	SELECT object_id
	FROM wp_term_relationships
	WHERE term_taxonomy_id
	IN (

		SELECT term_taxonomy_id
		FROM wp_term_taxonomy
		WHERE term_id =100
		OR parent =100
	)
)

Sostituendo DELETE al primo SELECT * cancello i post selezionati in precedenza, ma è sempre meglio controllare prima i dati!

Passo 4: pulizia

Una volta cancellati i post bisogna eliminare anche i loro riferimenti rimasti nella tabella `wp_term_relationships, che ci sono stati utili, ma ora non servono più.

Eseguirò quindi la query composta del punto 2 sostituendo DELETE al primo SELECT *.

E questo è tutto, ora mi posso dedicare con calma a capire perchè il pannello di amministrazione non funziona, ma questa è un’altra storia

Particolarmente interessanti sono i consigli di Schneider per il prossimo presidente degli Stati Uniti (chiunque sarà ), tant’è che ne consiglio la lettura anche ai nostri rappresentanti, nella versione curata da Communication Valley.