Archivi categoria: Development

Dedicata allo svilluppo del mondo Open Source.

Migrare WordPress su nuovo dominio

Wordpress logo

Migrare un sito in WordPress da un dominio ad un altro potrebbe apparire un’operazione semplice ma in realtà le cose sono complesse. WordPress memorizza in diversi punti nel database alcuni parametri associati al dominio stesso o al percorso locale in cui WP stesso è installato. Tutti questi riferimenti risultano spesso annidati in array serializzati e memorizzati in campi di database. Un’eventuale modifica “a mano” via phpMyAdmin quindi risulterebbe abbastanza scomoda e assai lunga.

Allora ho creato uno script (parser_WP.php) in PHP che modifica ogni riferimento presente nel database in modo da agevolare le operazioni.

Ricapitolando quindi, per migrare un sito WordPress su un dominio diverso, dovete:

  1. Copiare tutti i file e cartelle da un server ad un altro (via FTP, a partire dalla root)
  2. Creare un dump del database
  3. Creare un database vuoto sul nuovo dominio
  4. Importare il dump precedentemente creato
  5. Copiare lo script di cui sopra nella root del nuovo dominio e lanciarlo via browser (dopo aver configurato i dati di accesso al database)

Le modifiche da apportare al database sono di 2 tipi: sul dominio e sul path.
Aprendo lo script noterete che nelle prime righe vi sono 2 variabili da impostare:

$lookFor = "domain-1.com";
$replace = "domain-2.com";

Sostituite domain-1 con il nome del vecchio dominio e domain-2 col nome del nuovo dominio.

WordPress però, come dicevamo, memorizza anche il path assoluto in cui è installato. Dovrete quindi lanciare nuovamente lo script sostituendo le 2 variabili con i path: vecchio e nuovo. Ad esempio:

$lookFor = "/home/myOLDuser/";
$replace = "/home/myNEWuser";

Lanciate nuovamente il file. In questo secondo caso il risultato restituito (lo script restituisce il numero di valori modificati) sarà molto basso rispetto al primo (anche se questo varia a seconda dei plugin, widget, ecc. installati).

Fatto, ricordatevi di rimuovere lo script php dalla root!!

PHP: Nascondere errori “DEPRECATED” via .htaccess

logo-PHP

Sto installando un’applicazione in ambiente di prova, giusto per guardamela un po’ e per approfondire un po’ le funzionalità implementate. Peccato che l’applicativo in oggetto su PHP 5.3 genera una marea di errori di “DEPRECATED” dovuti alla funzione eregi ormai dichiarata obsoleta dal PHP 5.3 in avanti. Per velocizzare il tutto ho pensato di non visualizzare tali errori.

Le alternative sono diverse ma preferisco sempre aggiungere l’impostazione tramite file .htaccess in modo da “non sporcare” il codice sorgente. Ho quindi aggiunto un file .htaccess nella root del progetto aggiungendo questa riga:

php_value error_reporting 22527

Il livello 22527 corrisponde a  “E_ALL & ~E_DEPRECATED“, appunto tutti gli errori tranne i deprecated. Nel file .htaccess non è possibile inserire il testo, si può solo configurare tramite bitmask corrispondente calcolata sulla base delle costanti predefinite per error_reporting.

Se non siete ferrati sull’argomento bitwise operators o non avete voglia e tempo potete rapidamente calcolarvelo tramite queste 2 righe in PHP, la prima imposta il valore che desiderate (utilizzando le costanti e gli operatori bitwise) la seconda stampa a video la bitmask corrispondente (un numero intero) che poi potrete utilizzare per configurare il tutto tramite file .htaccess:

error_reporting( E_ALL & ~E_DEPRECATED );
echo error_reporting(); die;

 

Migrare Repository SVN


Metto qui insieme alcune risorse utili a migrare repository SVN. La soluzione migliore a mio avviso è quella di creare il dump di un repository per poi importarlo nel nuovo. Per creare un dump (se sono disponibili i comandi da riga di comando) lanciare da shell:

# svn dump my_repo_path > myRepo.SVNdump

Dove my_repo_path è il percorso in cui si trova il repository e myRepo.SVNdump è il file di output che andiamo a creare.

Dopo aver effettuato il dump e dopo averlo caricato nel nuovo Repo si blocca se non ha lo stesso UUID. E’ possibile modificare l’UUID di un Repository successivamente alla creazione del dump. E’ possibile inoltre forzare l’UUID quando si carica il Dump nel nuovo repo col comando:

# svnadmin load --force-uuid ...

Altre risorse utili:

 

 

Ottimizzare la shell per Git

Oh-My-Zsh è un framework per gestire al meglio la configurazione della shell Zsh. Include oltre 40 plugin (rails, git, OSX, ecc.) e oltre 80 temi. E’ facile da installare sul vostro sistema OSX e già la configurazione base aiuta notevolmente nell’utilizzo dei Repository Git, ad esempio. Come si vede dall’immagine sopra la shell riconosce che nella directory in cui si è posizionati vi è un repository Git e ne segnala il branch corrente. Io, oltre a git, ho abilitato anche il plugin per OSX:

  • aprire il file ~/.zshrc
  • modificare la riga: plugins=(git osx)

Chrome su OSX Lion lento (domini local)

Come ambiente di sviluppo sul mac utilizzo Zend Server CE e configuro i vari applicativi con domini locali del tipo:

esempio1.local
esempio2.local
ecc.

La configurazione è nel file /etc/hosts.

Chrome, il browser che prediligo per lo sviluppo, su questi domini risultava lento in fase di caricamento. In realtà era estremamente lenta la fase di interrogazione DNS per risolvere i vari nomi a dominio locali (come quelli sopra riportati). In un question su Stackoverflow ho scoperto che l’estensione .local (TLD) “it’s reserved for some Multicast DNS features (used by Bonjour)“. Rinominando i domini di cui sopra in:

esempio1.localdev
esempio2.localdev
ecc.

la velocità è tornata quella di sempre (estremamente veloce, trattandosi di domini locali).

Google Drive, backup file in cloud (come Dropbox?)

Dopo qualche giorno di attesa oggi mi è arrivata l’email con l’attivazione del mio account Google per il nuovo servizio Google Drive. Una sorta di Dropbox (sono molto simili, anche per lo spazio gratuito: per entrambi 5Gb) con un’unica differenza: l’interfaccia a Google Documents.

In pratica, dopo aver installato il client (si tratta di una Status Bar Application), viene creata l’apposita cartella modello Dropbox:

Poi viene avviata di default una sincronizzazione con tutti i documenti presenti nel Google Docs. Anche le icone vengono personalizzate e quando cliccate su un file/documento vi viene aperto il browser con la pagina in modifica del documento stesso.

Per ora non trovo altre differenze con Dropbox se non nei termini di servizio dove Google, senza farsi grandi problemi, scrive:

“When you upload or otherwise submit content to our Services, you give Google (and those we work with) a worldwide licence to use, host, store, reproduce, modify, create derivative works (such as those resulting from translations, adaptations or other changes that we make so that your content works better with our Services), communicate, publish, publicly perform, publicly display and distribute such content.”
Fonte: StartUp Wikli by @magno 

E’ evidente che poter disporre della licenza d’uso o di riprodurre, modificare, creare lavori derivati  dei nostri documenti, almeno per ora e sulla carta, è un notevole vantaggio da parte di Google rispetto ai concorrenti. Questo consente a BigG di poter aggiungere comodamente diversi servizi a tutti i nostri documenti (ad es: la traduzione automatica dei documenti come suggerisce @magno).

Come si muoveranno ora i concorrenti (Dropbox, iCloud, SkyDrive, Box, SugarSync, ecc.)?

 

 

Zend Server CE su OSX: lighttpd is not running

Dopo l’ultimo aggiornamento di Zend Server CE sull’iMac con Snow Leopard l’interfaccia web utente ha smesso di funzionare e l’indirizzo http://localhost:10081 risultava irragiungibile, così come il phpMyAdmin presente sullo stesso url.

Subito ho provato con il tentativo di riavvio di Zend Server da riga di comando:

iMacJazzo:log root# /usr/local/zend/bin/zendctl.sh start
Starting Zend Server 5.6.0 ..
Starting Deployment [OK]
[17.02.2012 13:13:18 SYSTEM] watchdog for zdd is running.
[17.02.2012 13:13:18 SYSTEM] zdd is running.
Starting Zend Server Monitor node [OK]
[17.02.2012 13:13:19 SYSTEM] watchdog for monitor is running.
[17.02.2012 13:13:19 SYSTEM] monitor is running.
/usr/local/zend/bin/apachectl start [OK]
spawn-fcgi: child spawned successfully: PID: 1367
Starting Zend Server GUI [Lighttpd] [OK]
[17.02.2012 13:13:21 SYSTEM] watchdog for lighttpd is not running.
[17.02.2012 13:13:21 SYSTEM] lighttpd is not running.
Starting Java bridge [OK]
[17.02.2012 13:13:21 SYSTEM] watchdog for java_daemon is running.
[17.02.2012 13:13:21 SYSTEM] java_daemon is running.
Starting JobQueue [OK]
[17.02.2012 13:13:22 SYSTEM] watchdog for jqd is running.
[17.02.2012 13:13:22 SYSTEM] jqd is running.
Zend Server started...

Da qui mi sono reso conto che c’era un problema su lighttpd. Con qualche ricerca ho trovato questo ottimo post sull’avvio di lighttpd in modalità debug:

# sudo /usr/local/zend/bin/lighttpdctl.sh --debug start

L’errore, come descritto anche nel post qui sopra, sta nei permessi della directoy: /usr/local/zend/etc/tls/
Per correggere l’errore basta inviare il comando:

# sudo chmod -R 775 /usr/local/zend/etc/tls/

Rilanciando lighttpd tutto fila liscio:

iMacJazzo:conf root# /usr/local/zend/bin/lighttpdctl.sh --debug start
spawn-fcgi: socket is already in use, can't spawn
[17.02.2012 13:24:02 SYSTEM] watchdog for lighttpd is not running.
[17.02.2012 13:24:02 SYSTEM] lighttpd is not running.
Starting Zend Server GUI [Lighttpd] [OK]
[17.02.2012 13:24:03 SYSTEM] waiting for process 1748
[17.02.2012 13:24:03 SYSTEM] Executing: /usr/local/zend/gui/lighttpd/sbin/lighttpd -m /usr/local/zend/gui/lighttpd/lib -f /usr/local/zend/gui/lighttpd/etc/lighttpd.conf -D
[17.02.2012 13:24:03 SYSTEM] watchdog for lighttpd is running.
[17.02.2012 13:24:03 SYSTEM] lighttpd is running.