Saluto a Drupal.

Veramente non c’è modo di avere vita facile con questo CMS.

Il problema è forse il farci troppo affidamento.

Uso drupal come un blog, e considero il blog come un modo di pubblicare contenuti, e mi aspetto che essi siano consistenti e atomici in qualche maniera, ovvero che possano esistere come entità.

Drupal supporta i contenuti in multi lingua, o me lo aspetto almeno, così dalla versione 7. E così mi aspetto che perfino le entità associate contenuto-traduzioni siano esse stesse una nuova entità molecolare, per così dire.

Ed è naturale aspettarsi che ci sia una modalità per poter salvare i contenuti, per poi reimportarli in un nuovo sito.

Il problema è provando ad usare il modulo migrate di drupal 8, tutto questo non viene considerato, tutti questi concetti sembrano non intervenire, e si atterra su di una schermata che elenca cosa verrà importato e cosa non funzionerà, che è qualcosa di assolutamente incomprensibile.

Dopo un fine settimana passato a combattere con un mostro succhia risorse ho quasi perso la speranza di recuperare i miei contenuti.

Questo lo trovo triste e sconsiderato, quasi un furto.

Quello che mi resta da provare è https://www.drupal.org/project/views_data_export , sperando che si possa recuperare i dati.

Mi accorgo che il semplice disinstallare un modulo in drupal 7 mi ha fatto perdere i dati, ma in realtà è solo un’illusione, i dati ci sono, ma il sito ha smesso di farli vedere. E non ne trovo le ragioni.

Ci sono “contenuti senza contenuto”, questo naturalmente è solo ciò che appare.

Evidentemente come per tutti i dati, anche un sito ha bisogno di backup, ma quali sono gli strumenti messi a disposizione per un backup.

Intendo, oltre a mantenere la copia del db e del filesystem, c’è un modo più agile e più univoco di salvare i dati?

Se un’articolo è al più una pagina di ipertesto con immagini, non sarebbe più semplice se fosse il framework ad occuparsi di esportarli, ognuno atomicamente, per poi spacchettarli come più gli piace?

Ovvero dato un contenuto le sue immagini potrebbero essere codificate in base64, in linea, ed essere quindi esportate verso un file di testo, o multipli file di testo.

Evidentemente si perderebbero delle informazioni semantiche. Ma dunque un xml con sessioni CDATA non sarebbe sufficiente? e quindi evitare anche la codifica delle immagini in linea, ma fara in una apposita sezione dell’XML con le informazioni relative al riferimento e alla posizione nel filesystem:

<blogentry>
<title>title post</title>
<content lang="it"><!CDATA[[.... ..]]></content>
<content lang="en"><!CDATA[[.... ..]]></content>
<images>
<image filename="/path/in/the/website"><!CDATA[[base64:.... ..]]></image>
</images>
</blogentry>

Ok, capisco che usare l’XML sia piuttosto agé, ma così almeno si può ragionare sull’esportazione/importazione in modo agnostico, invece di andare sempre a parare su codice e framework, e struttura del db, e via discorrendo.

I framework cambiano sempre e tutto si aggiorna, ma l’entità come un post di un blog dovrebbe rimanare tale.

Ovvio che si possono aggiungere metatag o qualsiasi cosa, ma tutto ciò che è necessario alla presentazione della pagina, nel senso di autenticamente relativo al contenuto (escludendo quindi i blocchi o decorazioni e campanelli), potrebbe essere impacchettato in una struttura semplice e leggibile da tutti. Da tutti i framework.