Créer des entrées de menu sans lien avec Drupal 8
Pour mon premier billet de blog, je vais faire la promotion des blogs de développeurs Drupal.
Ces blogs m'ont inspirés et m'ont dépannés dans certains projets professionnels
Pour ce premier billet de blog, j'ai envie de faire la promotion des blogs de drupalistes. À force de lire des articles de ces personnes j'ai eu envie à mon tour, d'en écrire afin d'essayer d'apporter un peu plus de contenu francophone concernant Drupal.
Voici les blogs que je fréquente et que je lis dès qu'un nouvel article sort.
Ce site à été construit à l'origine sous Drupal 6, migré sous drupal 7 en 2012, Je suis en train de préparer la migration de ce site vers Drupal 8 via la Migrate API.
Vu que je galère pas mal à trouver des exemples à jours, complets et qui fonctionne, je me suis dis que ce serait intéressant de partager mon expérience, le plus simple étant de partager directement mon module de migration, je l'ai donc mis directement sur github afin que vous puissiez piocher directement dedans pour voir comment je migre l'intégralité du contenu de ce site vers une installation de Drupal 8.
J'ai tenté de faire un readme assez complet, mais les recettes YAML ne sont pas encore super bien documentées, c'est à faire... Pour l'ensemble, c'est du glané à droite à gauche, sur internet mais aussi dans les exemples du module migrate_plus.
En vrac ce que vous pourrez trouver :
Sera fait dans les prochains jours :
Comme je l'ai dis, je me suis beaucoup inspiré du sous-module migrate_example de migrate_plus, c'est pourquoi il reste encore pas mal de commentaire en anglais faisant référence à des types de contenu « beer », qu'il faut que j'adapte.
Remarque : Je ne suis pas un expert de migrate, l'ensemble est probablement améliorable, mais comme disait un sage : « le mieux est l'ennemi du bien », je cherche avant tout à avoir quelque chose qui fonctionne. Ceci étant dit, n'hésitez-pas à me faire part de vos remarques, commentaires ou questions via les commentaires ou bien les issues sur Github ! Je suis preneur de toute idée d'amélioration.
Le tout est disponible sur Github : https://github.com/kgaut/kgaut_migrate.
Et c'est r'parti pour un DrupalCamp. Après Nantes nous voici conviés, pour ce rendez-vous 2017, à Lannion.
Comme tous les ans, les organisateurs des drupalcamp lancent des appels à partenariat.
Sur le site de l'événement, vous trouverez le détail des offres.
Avis aux entreprises : nous avons besoin de vous !
Mais cette année, nous avons aussi pensé aux participants et à leurs familles. Le camp se déroulant du 27 au 29 octobre prochain, pendant les vacances de la Toussaint, nous nous sommes dit que certains pourraient être tentés par une expérience bretonne un peu plus conséquente.
Alors si l'envie vous prend de profiter du camp pour visiter le coin, nous vous proposons de répondre à ce questionnaire rapide. Avec un peu de chance, nous pourrions vous proposer quelque chose.
Pour un projet en cours sur Drupal 8, j'ai besoin d'un moteur de recherche avec plusieurs indexes. J'utilise évidement le module search_api avec un moteur de recherche SolR, Vu que je suis en mode "développement" je vais utiliser une image docker qui me fournira une installation fonctionnelle de SolR, directement plugable avec Drupal.
Par habitude j'utilise les images de Thiebaud Schmittlin : https://github.com/TehesFR/docker-solr
Une fois docker installé l'image se lance avec la commande suivante :
docker run -p 8080:8983 tehes/docker-solr:4.10
Cela lancera une image SolR 4.10 sur le port 8080, si on souhaite utiliser une autre version du moteur il suffit d'adapter le tag :
docker run -p 8080:8983 tehes/docker-solr:6.6
Par contre dans mon cas, j'avais besoin de plusieurs cores pour mes différents indexes, j'ai donc adapté son image pour en créer une nouvelle : https://github.com/kgaut/docker-solr-multicore
C'est du « quick'n'Dirty » Je me suis basé uniquement sur la version 6.6 de SolR, la seule modification par rapport au DockerFile original est l'ajout d'une variable NB_CORES qui est par défaut à 4. L'image créé donc 4 core permettant d'avoir 4 indexes.
J'ai mis mon image sur Docker hub : https://hub.docker.com/r/kgaut/docker-solr-multicore/
Pour lancer l'image :
docker run -p 8080:8983 kgaut/docker-solr-multicore
Si jamais vous avez besoin de changer le nombre de cores, vous pouvez modifier cette image de la façon suivante :
git clone git@github.com:kgaut/docker-solr-multicore.git my-docker-solr-multicore cd my-docker-solr-multicore
Modifiez le fichier DockerFile et à la ligne 11 remplacez "env NB_CONTAINER 4" par "env NB_CONTAINER 8"
Construisez votre image (cette étape peut prendre un peu de temps) :
docker build -t my-docker-solr-multicore .
une fois terminée, lancez l'image :
docker run -p 8080:8983 my-docker-solr-multicore
et bim ! 8 cores :
Je suis loin d'être un expert docker, et si vous connaissez un moyen de passer le nombre de core voulu lors du lancement de l'image, je suis preneur. Même si vu que les cores sont créés au moment du build de l'image, je ne suis pas bien sur que cela soit possible...
Si vous avez d'autres idées d'améliorations, n'hésitez-pas, merci !
Comme pour la saison dernière, mon site mespronos.net vous proposera de faire vos pronostics sur la saison 2017-2018 de « Ligue 1 Conforama » (oui, c'est comme ça qu'il faut dire maintenant...)
C'est toujours évidement gratuit, toujours la possibilité aussi de créer ses propres groupes pour faire un concours entre amis ou collègues.
Commencé à l'origine pour mettre les mains dans drupal 8 à l'époque des premières version alpha, le module est en version alpha depuis un an maintenant, j'ai bon espoir de sortir une version beta d'ici le mondial 2018. Le code est disponible pour les curieux sur github, ainsi que sur drupal.org. Alors, oui avant de sortir une version stable, il y a beaucoup de chose à refactoriser afin que le code soit plus propre !
En déplacement au Maroc, l'association Drupal Morocco m'a demandé si je voulais animer un meetup un soir avec une présentation.
J'ai accepté et ai donné une présentation sur les sujets suivants :
Vous souhaitez permettre à vos éditeurs de contenu de facilement récupérer et intégrer des médias, images, vidéos, sons, présentations issus de plateformes tierces ? La suite Media entity dispose d'une corde supplémentaire à son arc avec le module URL embed.
Contourner l'erreur : "The SQL storage cannot change the schema for an existing field"
admin
mar 11/07/2017 - 09:02
Je vous partage aujourd’hui une astuce qui peut vous épargner de perdre quelques cheveux. Il s’agit de l’erreur suivante :
The SQL storage cannot change the schema for an existing field (field_meta_keywords in taxonomy_term entity) with data.
Cette erreur survient lorsque vous avez créé un champ et que vous avez configuré ses settings, que cette configuration est passée en production et que vos utilisateurs ont créé du contenu qui remplit les données de ce champ.
Il arrive que vous ayez besoin de modifier la configuration de ce champ. Simple me direz-vous ? Et bien non, pas toujours car Drupal ne va pas vous laisser faire (à raison).
Selon le type de champ que vous modifiez, les settings du champ peuvent être utilisés pour créer les colonnes de la table. Avec du contenu dans la table, hors de question de vous laisser faire n’importe quoi au risque de perdre des données. Drupal va donc lever une exception (FieldStorageDefinitionUpdateForbiddenException
) qui est assez explicite, pas de mise à jour du stockage du champ lorsque des données sont présentes.
Comment contourner cela ?
Vous pourriez tenter de modifier directement le fichier .yml de configuration de l’instance du champ à la main mais cela ne contournerait pas votre problème, Drupal comprendrait toujours que vous voulez modifier la configuration et vous protégerait contre la perte de vos données.
La seule solution pour cela est de travailler à un plus bas niveau via un hook_update_N()
pour faire le changement de configuration. Il faudra travailler directement sur les fonctions de base de données pour manipuler les colonnes.
Voici donc le code qui permet de faire cela :
/**
* Changement du schéma de field_meta_keywords stocké dans la configuration.
*/
function project_social_update_8006() {
// Augmentation de la longueur max du champ de 255 à 500 caractères.
try {
// 1. On vide le cache de la définition des champs pour travailler les mains libres.
\Drupal::service('entity_field.manager')->clearCachedFieldDefinitions();
// 2. On récupère la définition de notre instance de champ depuis les fichiers de config et on la sauve.
$storage_definition = \Drupal::service('entity_field.manager')->getFieldStorageDefinitions('taxonomy_term')['field_meta_keywords'];
\Drupal::service('entity.last_installed_schema.repository')->setLastInstalledFieldStorageDefinition($storage_definition);
// 3. On récupère la définition du champ.
$field_schema = \Drupal::keyValue('entity.storage_schema.sql')->get('taxonomy_term.field_schema_data.field_meta_keywords');
// 4. On définit la nouvelle valeur de notre configuration.
$field_schema['taxonomy_term__field_meta_keywords']['fields']['field_meta_keywords_value']['length'] = 500;// 6. On applique notre nouvelle configuration dans le stockage du champ.
\Drupal::keyValue('entity.storage_schema.sql')->set('taxonomy_term.field_schema_data.field_meta_keywords', $field_schema);
}
catch (SchemaException $e) {
\Drupal::logger('project_social')->error($e->getMessage());
}
}
La solution a été réalisée suite à ce patch très inspiré de Berdir qui montre la voie de l'implémentation : https://www.drupal.org/node/2641828#comment-10711058
Bien que l'on ait utilisé les fonctions de bas niveau pour faire les modifications, on aura tout de même exporté la configuration dans son état final pour s'assurer que le la longueur du champ de l'exemple est bien définie à 500 caractères. Cela permet de ne pas détecter de diff une fois notre correctif effectué. (L'export YML et la définition en base doivent être raccords).
Il est à noter évidemment que si vous aviez dû faire des modifications plus compliquée du type supprimer une colonne il aurait fallu des étapes supplémentaires pour ne pas perdre des données. Vous saurez maintenant comment vous y prendre.
Image de couverture par Florent Darrault, via Wikimedia Commons.
Les différents modules et techniques pour mettre en place une couche de services web sur une base de site Drupal 8.
Comment imiter le comportement de SPIP et découvrir Drupal pour les amateurs de ce CMS.
Bien que de nombreux articles existent déjà et que régulièrement de nouveaux en sont écrits sur ce qu'est Composer et comment s'en servir avec Drupal, voici un petit rappel.
Composer est un outil de gestion de paquets PHP, il permet de :
télécharger des librairies (principalement) PHP avec leurs lots de dépendances,
gérer les mises à jour de ces librairies,
exécuter des scripts, renseignés dans son fichier composer.json.
Nous avions abordé dans un précédent billet (Une feuille de route pour Drupal 8, et après ?) la nouvelle politique de Drupal 8 en matière de gestion de version, de support et de maintenance de ses versions mineures et majeures. Cette politique a quelque peu évoluée depuis la dernière conférence DrupalCon Baltimore en avril 2017. Et cette évolution de la stratégie de Drupal mérite qu'on s'y attarde quelque peu car elle peut amener un nouvel éclairage à ceux qui hésitent à migrer leur site sur Drupal 8.