La pratique de l'export dans Drupal a récemment été l'objet de notables progrès, depuis l'adoption de Ctools au sein même des modules. Même si vous utilisez dbscripts, il semble que les bonnes pratiques vous incitent désormais à utiliser les développements disponibles directement dans les modules contribués, en ce qui concerne les manipulations d'export.
La pratique de l'export dans Drupal a récemment été l'objet de notables progrès, depuis l'adoption de Ctools au sein même des modules. Même si vous utilisez dbscripts, il semble que les bonnes pratiques vous incitent désormais à utiliser les développements disponibles directement dans les modules contribués, en ce qui concerne les manipulations d'export.
Les modules suivants sont maintenant reconnus pour permettre, de façon robuste, l'export de leurs valeurs de configuration pour le code :
- Views
- Panels
- Flag
- Context - En ce qui concerne les Blocs de positionnement et visibilité
- Strongarm - En ce qui concerne les données stockées dans les tables de variables
- Features - En ce qui concerne les types de contenu et de leurs champs, les rôles et les permissions, ainsi que les formats d'entrée.
En outre, le module Features dispose d'un support pour le regroupement des exports de views, les panels, le context et StrongARM en "paquets" (c'est à dire un module de "fonctions"). Il est donc plus aisé de prévoir un ré-export ces valeurs avec la configuration à jour, à la fois par l'intermédiaire d'une interface web que d'une commande drush.
Le jour où ces pratiques seront largement adoptées par la communauté, dbscripts deviendra obsolète.
A noter :
Les éléments suivants sont d'autres systèmes de déploiement : Patterns, CoCKTaiL, Deploy, Exportables.
Vous noterez également, au passage, que l'ancienne méthode de fusion de base de données commence à annoncer qu'il devient préférable, de plus en plus, d'utiliser les techniques décrites ci-dessus.
