Mi scuso per l'italiano scritto, ma sono inglese, qui in italia da 25 anni, ma nonostante cio' (e un tastiera inglese) il risultato e' quello che e'.
Uso Drupal (6.x) professionalmente da quasi un anno, leggo questo sito oltre che www.drupal.org ed altri, ed ho sviluppato un processo di istallazione (come tanti, immagino). Voglio descriverlo qui per vedere se, secondo voi esperti e non, il ragionamento fila. Ringrazio a priori le risposte, ed anche la pazienza necessario per leggere tutto questo.
Mettero' dei numeri cosi' che si puo' rispondere anche ad uno o piu' punti. Purtroppo questo post sara' lungho...
0. Premessa. Dato che gli server che uso (esclusivamente shared hosting esterni) sono sempre linux, anch'io uso linux per lo sviluppo del sito. Quello che descrivo qui probabilmente vale anche per Windows, comunque. Non ho domestichezza con i profili (letto la documentazione, ma mi sembra un po' complesso) per creare un istallazione Drupal + n moduli + m temi. Sono programmatore, ma non ho una profonda conoscienza ne' di PHP ne' di Drupal al livello degli API. Il shared hosting deve fornire servizi sia di FTP sia di SSH, oltre ovviamente a mysql, PHP, e Drupal.
1. Per un nuovo shared hosting, spedisco una 'respository' Drupal tramite FTP sul server che comprende il core, moduli e temi che uso abitualmente, ma ancora compressi, tipo drupal-6.x/core/drupal-6.14.tar.gz, drupal-6.x/modules/backup_migrate-6.x-1.2.tar.gz, drupal-6.x/themes/zen-6.x-1.0.tar.gz, ecc. Ho anche certi moduli da me modificati, che tengo (sempre in tar.gz) in drupal-6.x/modified/modules/... ma nel file .info rimuovo l'informazione creato dal drupal.org packing script. Con FTP si impiega un bel po', ma solo una tantum.
2. Per un nuovo sito esempio.it prima uso Fantastico sul shared hosting per creare l'applicativo Drupal 'nudo e crudo'. Questo e' quasi sempre una versione indietro (oggi mi da 6.13, mentre Drupal.org ha il 6.14), ma pazienza. Prendo nota del nome della schema DB, utente, password, ecc. Poi sul mio computer costruisco 'a mano' un sito identico, in localhost, ma con l'URL dev-esempio.it. E' abbastanza semplice, usando /etc/hosts, il config di Apache2, e due commandi mysql - posso spiegarlo in dettaglio, ma questo post sara' gia' troppo lungho cosi com'e'.
3. Lavorando col terminale in localhost, e Putty (telnet/SSH) su shared hosting, per entrambi i siti, aggungo due indirizzari modules e themes in sites/all e anche in sites/default.
4. Per l'applicativo shared hosting che non ha l'ultimo versione di Drupal, espando l'ultimo versione di Drupal in un indirizzario temporaneo, e copia questi file nel indirizzario del sito.
5. Per entrambi gli applicativi (shared hosting e localhost) espando gli moduli e temi che mi serve. In realita' questo puo' essere una lista molto breve: Administration Menu, Backup and Migrate, e Zen theme. I moduli e temi modificati da me vanno esclusivamente in sites/default.
6. Metto entrambi i siti in maintenance mode. Lancio update.php. Abilito moduli e temi, poi lancio di nuovo update.php.
7. Prendo l'ultimo traduzione di Drupal in italiano (c'e' un sito favoloso, lo conoscete?), e faccio l'upload del file drupal-6.x-it.po su entrambi i siti.
8. Tolgo il maintenance mode.
Bene. Fin qui mi sento abbastanza securo. Per creare un secondo sito sul shared hosting, ripeto punti 2 a 8. Escluso la creazione del 'repository' che puo' durare dai 30 ai 60 minuti dipende dalla velocita' di FTP (porto fuori il cane), il resto consuma 30 minuti cerca.
Il sequente punto e' un po' piu' grigio per me...
9. Ho visto (esperimentando, non ho trovato documentazione, ne' letto il codice sorgente) che se per esempio ho modificato un modulo), posso copiarlo da sites/all/modules a sites/default/modules, e se tolgo l'informazione creato dal drupal.org packing script (sempre le ultime righe nel file .info), Drupal 'vede' solo il modulo modificato, e non quello originale (anche se esiste ancora in sites/all/modules), e non fornisce piu' informazione di aggiornamento. Ovviamente, quest'ultimo e' importante perche' l'ultima cosa che voglio e' di sovrascrivere il mio lavoro con l'ultimo release del modulo. E' un comportamento di Drupal corretto, o solo due errori che compensano? (By design or by mistake?)
Se trovo conferma per il punto 9, posso completare un programma per automatizzare punti 3 a 8, ma anche per automatizzare l'aggiornamento dei siti, che spiegero' in un altro occassione.
Intanto, modificare un modulo fatto da altri non è una grande idea. Probabilmente quello che vuoi fare si può fare con un modulo scritto da te, che modifica alcune delle funzioni del modulo.
Detto questo, se proprio devi modificare un modulo, basta metterlo nel punto più "alto" nel seguente elenco:
È normale che venga usata solo una versione del modulo, altrimenti PHP caricherebbe al bootstrap diverse funzioni duplicate e si bloccherebbe.
Affascinante. Ovviamente io ho perso qualcosa nella mia lettura. Certo che preferisco non modificare un modulo da altri (in questo momento sto modificando webform per produrre un risultato calcolato nella form immessa). Marcello, mi puoi dare quale link su come si fa ereditare un modulo x per poi modificarlo in x'? Ho provato rispolverare i miei libri, e richercare con "how-to modify existing drupal module" e "how-to inherit existing drupal module" ma senza risultati interessante.
Perfetto. By design, quindi.
Presumo che il resto fila abbastanza liscio.
Grazie per la risposta.
John
Più imparo, più dubito.
Per modificare un modulo, devi andare a vedere quale hook viene usato nella fase che ti interessa modificare e agire di conseguenza.
Per esempio, se vuoi modificare un form creato da un altro modulo, crei una funzione hook_form_alter in un tuo modulo e vai a fare diverse cose:
- vedi qual è il form_id del modulo creato dall'altra parte
- usi il form_id per definire su quale modulo agisci
- fai le modifiche agli elementi del form usando la FormAPI
- se per caso hai aggiunto o tolto campi, dovrai anche andare a modificare le funzioni _submit e _validate del modulo per gestire i nuovi valori
Grazie della risposta. Molto chiaro - eccetto l'ultimo punto. Dato che PHP non permette la ridefinizione di una funzione (se ho capito bene dal tuo penultimo risposta), ritengo che se aggiungo o tolgo un campo allora devo modificare il codice del modulo stesso. Corretto?
Nel esempio Webform, ho aggiunto un componente (nuovo file), aggiunto una voce menu (hook_menu), modificato i links nella pagina risultati, e qualche altro ritocco che adesso ho dimenticato. Con tutti questi modifiche, mi pare che ho solo questi possibilita':
modwebform, ma sewebformviene aggiornato, i diffs mi dira' anche tutti i cambiamenti dei funzioni, dawebform_...amodwebform...- piu' un problema che una soluzionewebform, modificarlo, poi gestire da me problemi di merge quando faccioupdatedel moduloHo continuato la mia lettura (Pro Drupal Development, per citarne uno). A questo punto mi sembra che Drush, che ora non e' piu' un modulo, ma un script esterno, sia un buon punto di partenza. Se uso sempre versioni CVS dei progetti posso continuare a modificarle come punto 2 sopra. Ovviamente, se le modifiche piacciono al autore/maintainer del modulo, posso mandare un patch, ma se non - mi lo tengo per me. (Escludo teme da questo discorso, perche' e' abbastanza facile creare un sotto-tema.)
Mi rimane un ulteriore problema. La configurazione di Drupal - o meglio il database. So che questo non e' un problema facile.
E' chiaro che finche' sono solo io a fare modifiche, posso trasferire il database dal sito 'sviluppo' al sito 'produzione' e vice versa, senza problemi, ma che fare, diciamo tre mesi da ora, quando altri utenti hanno creati contenuti?
Faccio un esempio 'worst case'. Devo modificare il sito, aggiungendo altri moduli, cambiando certi valori di configurazioni, diciamo che impiego quattro giorni. Che faccio? Il mio approccio e' questo (fino ad adesso non l'ho messo alla prova, francamente mi terrorizza):
Chairo che faro' backup dei database prima di questi operazioni chirugici. Scrivendo questo mi rendo conto che probabilmente e' meglio fare diff col database 'produzione', perche' qualcun'altro puo' aver cambiato qualche valore di configurazione, oltre ai data.
Fila il ragionamento?
Più imparo, più dubito.
Su drush c'è chi è più esperto di me.
Riguardo alla prima parte della domanda: no!
Se devi per qualche motivo cambiare la funzione submit legata a un form, allora
- devi cambiare con hook_form_alter la chiamata alla funzione submit del form (che non sarà più quella del modulo originale)
- creare una tua funzione _submit (quella chiamata dentro hook_form_alter) in cui replichi le funzioni che ti interessa salvare della funzione originale e aggiungi le tue
Grazie ancora degli ulteriori spiegazioni...
Nei prossimi giorni faccio qualche prova con drush e un istallazioni drupal sotto CVS. Qualcuno ha qualche esperienza, qualche dritto?
Insomma, non mi lasci sporcare il codice degli altri! Sigh. Messagio ricevuto, studiero' meglio gli hooks.
Ed io che volevo usare Drupal per non programmare piu'.
FYI, capisco benissimo gli motivazioni, ma essendo pigro (non credo che saro' l'unico) mi sembra un po' macchinoso - ma molto OOP.
Quindi gli hook mi forniscono una specie di overloading per funzioni negli altri moduli. Ci provero'.
Più imparo, più dubito.