Newsgroup: it.lavoro.professioni.webmaster
Titolo: Wordpress: sviluppare in locale e poi trasferire sul server oppure ...?

Ciao a tutti, devo realizzare un sito su piattaforma Wordpress per un 
cliente che ha gi� un sito pubblicato, sicch� vogliamo ridurre al minimo 
i tempi di offline.
 
La prima possibilit� � quella di svolgere il lavoro in locale, poi 
trasferire il tutto in remoto e qui la prima domanda: nella vostra 
esperienza, l'operazione di trasferimento pu� essere problematica?
 
L'alternativa a cui avevo pensato sarebbe questa: il cliente ha il 
dominio registrato sotto Aruba con hosting Windows, si potrebbe 
modificare il servizio in hosting Windows + Linux lavorando sotto 
quest'ultimo poi modificare il puntamento del www nelle impostazioni del 
dominio da Windows a Linux.
 
In questo modo il cliente potrebbe vedere il lavoro man mano che viene 
effettuato e richiedere le modifiche desiderate.
 
E' una buona idea?
 
Grazie dell'attenzione e dei suggerimenti che mi darete.
 
Paolo

 E' una buona idea?
 
ottima, una volta ho lavorato anche io esattamente in questo modo, tutto ok.
 
nulla vieta in ogni caso di impostare comunque il sito localmente per fare prima (immagino i tempi di reazione su un server locale siano inferiori), poi quando è ben imbastito metterlo su.
 
occhio comunque alle richieste in corso d'opera del cliente: in genere sono sempre grosse rotture di cazzo.  meglio mettersi dìaccoro *molto bene* *prima* dell'inizio del lavoro.


 
S� conosco bene questo tipo di problemi con i clienti ... ma se devo 
fare qualche modifica, e discuterne, preferisco saperlo man mano 
piuttosto che a lavoro ultimato.
 
Grazie della risposta.
 
Paolo

 Paolo
 
Ciao
Una delle pecche più grosse di wordpress  è che mette l'url assoluto del 
sito dentro la tabella wp_posts
Il risultato è che se tu sviluppi su sitocliente.miodominio.tld devi 
ricordarti di aggiornare a mano il db quando pubblichi su 
www.sitocliente.tld
 
L'alternativa è sviluppare localmente usando www.sitocliente.tld e 
dirottare il proprio browser tramite file hosts (questo è il mio 
suggerimento)
 
Se non devo mostrare niente durante lo sviluppo io di solito uso 
quest'ultima opzione, altrimenti metto su il lavoro su 
sitocliente.marcoalbarelli.eu
 e quando è ora trasferisco tutto, tenendo 
conto che ti parte una mezz'ora almeno fra upload, fix del db e 
controllo che tutto vada bene
 
È anche possibile sviluppare localmente usando www.sitocliente.tld e lo 
stesso permettere al cliente di vedere lo stato andando su (esempio) 
sitocliente.miodominio.tld, ma ti servono un DNS manipolabile 
direttamente, una linea adsl decente e un router domestico che permetta 
l'inoltro di porte (più un esercizio di stile che una reale soluzione)
 
Giusto per riferimento, di solito bastano poche query per sistemare il db
 
UPDATE wp_posts SET post_content = REPLACE( post_content, 
'
oldomain.com
', '
newdomain.com
' ), guid = REPLACE( guid, '
oldomain.com
', 
'
newdomain.com
' );
 
UPDATE wp_postmeta SET meta_value = REPLACE( meta_value, '
oldomain.com
', 
'
newdomain.com
' );
 
UPDATE wp_options SET option_value = REPLACE( option_value, 
'
oldomain.com
', '
newdomain.com
' );
 
Un problema possono essere i plugin: ne ho sperimentati un paio che 
salvavano nel db oggetti serializzati contenenti l'url assoluto delle 
risorse.
In quel caso devi andare a manina a modificarti gli oggetti in quanto un 
semplice replace porterebbe ad un oggetto non deserializzabile
 
-- 
I fatti mi cosano

Il 18/03/2013 12:06, Marco Albarelli (fu Motosauro) @fisso ha scritto:>
 
 > Una delle pecche pi� grosse di wordpress  � che mette l'url assoluto del
 > sito dentro la tabella wp_posts
 > CUT
 
Grazie anche a te della risposta molto precisa e completa.
 
Paolo
 

 risorse.
 
Esatto, questo è il problema maggiore (oltre alla memorizzazione di 
possibili percorsi assoluti ai file), pero' esiste uno script all'uopo, 
che ho usato qualche volta e mi ha sempre funzionato:
 
https://github.com/ErisDS/Migrate
 
 
NB: non lo uso da un po' di tempo.


Quando mi sono accorto del problema degli oggetti serializzati ero in 
fase di deploy di un sito finito e meno male che di solito faccio questi 
lavori dopo la mezzanotte ...
Alla fine nel mio caso si parlava di tre oggetti di numero, quindi ci ho 
messo meno a farlo a mano lato mysql (con la palla di contarsi la 
lunghezza delle stringhe prima e dopo) . Ne avessi avute di più da 
cambiare avrei anch'io optato per uno script, trovato in rete o scritto 
a mano
 
Quello che hai linkato non mi pare gestisca la migrazione dentro oggetti 
serializzati (maledetta la volta che quelli di wordpress hanno permesso 
una cosa simile e maledetti quelli che scrivono plugin con quel dato 
serializzato)
Peraltro non so nemmeno come se ne potrebbe fare uno generico, forse 
provando a deserializzare ogni riga dell wp_options o magari facendo una 
search/replace più complesso tipo s\::num\{\"http\:\/\/   ...


>> risorse.
 
Ma quando periodicamente saltano fuori discussioni sui vari cms 
bisognerebbe dirlo (ok, una minima possibilità che sia io a non averlo 
mai sentito c'è, visto che wp lo uso pochissimo :) ) che wordpress si 
porta dietro una assurdità simile.
 
 
-- 
Paolo De Dionigi

 serializzati 
 
mi sa che ho fatto confuzione io, ho cercato al volo nella cronologia 
senza verificare, mi sa che lo script è questo:
 
http://interconnectit.com/products/search-and-replace-for-wordpress-
 
databases/


Che sia una assurdità concordo in pieno
È una di quelle cose che impari abbastanza presto e poi tendenzialmente 
la dimentichi perché la eviti come prima cosa
Francamente non ho ancora capito come mai se la tirino dietro
 
Di fatto non è poi sto enorme problema dato che lavorando sul file hosts 
puoi sviluppare in locale


Paolo E. ha scritto:

Giusto l'altro giorno ho letto questo, non faceva al caso mio, al tuo forse.
 

  > sito dentro la tabella wp_posts
 
questa risposta miha fatto venire in mente che quano il sito è onine è anche necessario modificare a mano, nella tabella wp_options tramite phpmyadmin o simili, l'url dell'home page del sito.  se non sbaglio dovrebbero essere i record 9 e 39, ma scorrendo "a mano" li si vede subito.