drupal7

Sono consapevole che oggigiorno parlare di Drupal 7 "puzza un po' di vecchio" dal momento che tutta la community è giustamente orientata verso l'utilizzo e l'evoluzione di Drupal 8. Certo è che a me capita ancora di lavorare su numerosi progetti web sviluppati in D7 e secondo le ultime notizie sarà supportato fino a Novembre 2021. Quindi non trovo fuori luogo trattare argomenti per migliorare il codice dei propri progetti in D7.

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

Quando l'ambiente dove sviluppi non ha le stesse cofingurazioni di quello di produzione, sta sicuro l'inghippo sta dietro l'angolo. L'ideale sarebbe di poter sempre lavorare con strumenti e piattaforme che ti permettono di avere ambienti allineati in modo da minimizzare al massimo eventuali problemi in fase di rilascio. Ma non sempre è così, soprattutto quando, come in questo caso, il cliente ha già il suo hosting o i suoi server dedicati.

Nel progetto che stiamo realizzando con Drupal Commerce mi si è posto difronte una problematica alquanto insolita: disabilitare il tab menu in alto a destra "View | Edit" in base al ruolo dell'utente loggato.

Oggi ho scoperto che in Drupal Commerce alcuni campi non possono essere editati a piacere (locked fields). Nel caso specifico sto parlando del campo prezzo. A quanto pare sembra essere un'imposizione dettata dalla struttura di Drupal Commerce motivata dal fatto che il prezzo viene ricalcolato per ogni nuovo utente/acquirente che si registra. Questo permette di definire prezzi diversi in base all'utente (fonte www.drupalcommerce.org).

Questa mattina ho scoperto che Drupal 7 ha modificato il modo di gestire il nome dei template files. Tempo fa, in un progetto con Drupal 6, avevo modificato la funzione mytheme_preprocess_page(&$vars) presente nel file template.php per poter gestire template diversi su pagine differenti basandomi sul URL alias della pagina stessa.