Roberto Peruzzo

In questa prima settimana di Luglio sono volato a Lisbona per partecipare ai Drupal Dev Days, uno degli eventi europei più interessanti per chi come me lavora con Drupal. Quest'anno ho avuto il piacere di poter partecipare come speaker per poter condividere alcune mie idee su come risolvere i problemi legati all'inserimento di un nuovo sviluppatore all'interno di un team di lavoro.

In questo post vedremo come prendere i dati da un file CSV e salvarli dentro una tabella creata ad-hoc all'interno del database della nostra web application fatta in Drupal. Per la lettura e l'importazione dei dati utilizzando lo statement MySQL LOAD DATA INFILE che ci permette di fare tutto in un colpo solo.

L’anno scorso mi sono trovato di fronte ad un problema alquanto scomodo: ristrutturare gli URL dei contenuti presenti nel sito di un cliente per migliorarne la leggibilità e l’indicizzazione nei motori di ricerca. Tralasciando tutte le questioni inerenti ai redirect 301 da gestire, voglio concentrare questo post sulle performance raggiunte per aggiornare più di 200.000 path alias.

Quest'oggi volevo condividere con voi un post che avevo scritto l'anno scorso su Drupal.org, utile per chi deve eseguire dei processi batch per aggiornare grosse moli di dati. Per evitare che il processo vada in timeout, invece di eseguire l'aggiornamento su tutto in un unica passata, effettueremo più aggiornamenti su porzioni di dati fino a completamento.

Il problema di fondo è che i file delle immagini di default che imposti nel tuo ambiente di sviluppo non possono essere trasferite in modo automatico nei vari ambienti con il solo utilizzo di Features. Quando imposti un'immagine di default e poi esporti con Features quel campo, ciò che viene memorizzato è il fid del file che hai caricato. Ma quel file è presente nel tuo ambiente e non negli altri; inoltre non puoi garantire che l'identificativo fid del tuo file possa