Migrazioni e migrazioni

https://events.drupal.org/sites/default/files/slides/Migrating Multilingual Content to Drupal 8.pdf
Apprezzo le slide del pdf, e https://evolvingweb.ca/blog/migrate-translations-csv-json-or-xml-drupal-8

Sembra che per fare la migarazione dei contenuti da un drupal 7 (o 6) a drupal 8, ci si affidi ad delle definizioni di mapping tra le 2 piattaforme, e in modo piuttosto furbo, non essendoci niente di operativamente complesso, il formato yaml corrisponde ad una procedura eseguita, come in tante parti col framework symfony (approfondire questo aspetto).
E sì, è proprio per approfondire questo aspetto che ho intenzione di portare avanti l’aggiornamento di drupal alla versione 8. Non certo perché lo ritenga una piattaforma valida, ma perché mi incuriosisce l’architettura software, che per altro è assolutamente inadatta a qualsiasi applicazione reale, evidentemente.

Ma ciò che mi incuriosisce sono i pattern, l’organizzazione delle classi, e le funzionalità di symfony.

Cerco su internet e trovo sempre chi sostiene che “drupal 8 è lento però …” e poi fa seguire qualcosa che riguarda l’estensibilità o le funzionalità o la “potenza”, cosa del tutto inopportuna, ma piuttosto comune tra gli acquirenti dei SUV a dire la verità.

D’altra parte trovo confronti che, parlando di sicurezza, si schierano nettamente a favore di Drupal 8 rispetto a WordPress come piattaforma.
Il parallelo drupal-SUV sembra essere calzante.

Ho sempre pensato che se devi andarci a lavoro, e non sei un autotrasportatore, dovresti preferire una utilitaria che consumi poco a qualsiasi altra opzione.

Se però arrivato al lavoro non puoi chiuderla e rischi di farti fregare le chiavi di casa che poco furbamente ci tieni dentro, allora il risparmio si traduce in perdita.

Così suppongo che sia per le piattaforme. Per redigere un blog non c’è alcuno bisogno di utilizzare una piattaforma ultra tecnologica e sicura, se la si usa per pubblicare dei contenuti. E dunque, wordpress va benissimo, a patto che non gli si faccia gestire dei soldi.

Ed ecco che le estensioni wordpress per fare ecommerce sembrano del tutto inopportune.

D’altra parte per far girare drupal ci vuole un bel po’ di pazienza, oppure una macchina con buone prestazioni.

Dunque, il mio side-project in questo momento è portare i contenuti verso drupal8, per poi metterci il blog personale.

È effettivamente un contro senso per quanto ho scritto sopra, ma è sensato nell’ottica della capitalizzazione in conoscenza che deriva dal fare il porting, e anche dall’avere a che fare con la piattaforma.

In sostanza perdo tempo sperando sia un guadagno

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.