Pred časom som pre jedného klienta programoval jednoduchý modul na integráciu so službou tretej strany. K tomu, aby fungoval, bolo potrebné mať vygenerovaný API kľúč, ktorý som v module ukladal do konfigurácie. Keď som konfiguráciu vyexportoval a pushol na github, prakticky o niekoľko sekúnd som dostal e-mail o tom, že kľúč bol kompromitovaný. Akoby nie - bol to verejný repozitár a tak ho mohol vidieť ktokoľvek. Hneď prvé riešenie, ktoré mi napadlo, bolo nastaviť repozitár ako privátny.

Predstavte si takýto scenár: Máme view nejakého typu obsahu. Každá entity má priradený nejaký taxonomy term no a my chceme tento obsah podľa tohto taxonomy term filtrovať. Inými slovami: chceme zobraziť len ten obsah, ktorý má priradený určitý taxonomy term. Jednoduché, že? Vytvoríme príslušné view na lokálnom prostredí. Všetko funguje. Potom to pushneme na produkciu a čo? Veď na produkcii to nefunguje, prečo? No pretože taxonomy term ID na našom lokálnom stroji je s najväčšou pravdepodobnosťou iné ako na produkčnom serveri.

Nedávno som pracoval na jednom projekte, kde som potreboval modul Webform a k nemu nejaký jednoduchý workflow. K tomu mi úplne stačil modul Workflows v core spolu s modulom Webform Workflows Element, ktorý do webform pridá element, cez ktorý si môžem pre príslušný webform submission nastaviť stav. Umožňuje dokonca aj pridať dve log správy o zmene stavu - jednu pre odosielateľa formulára a jednu pre administrátorov.

Pre jedného klienta robím upgrade webu z Drupal 6 na Drupal 9. Tentokrát som sa rozhodol, že sa hlbšie ponorím do Drupal Migrate API a použijem ho na migráciu obsahu. Všetko šlo ako po masle, až pokiaľ so nenarazil na migráciu obrázkov. Samotné súbory som zmigroval bez problémov, podobne aj obsah, jediné, čo mi nešlo, bolo prepojiť file entity s obsahovými entitami. Na starom (Drupal 6) webe boli vo fielde field_news_images, na novom sa pole volá field_images.