Contexte

Dans un an, mes clients vont porter un service de portail intranet relativement complexe (planification, suivi et rapports réels, etc.) vers Drupal parce que le siège social le dit. Très peu d'efforts ont été faits pour déterminer si c'est le bon choix technique et cela échappe au contrôle de mon client ou même de ses patrons.

Le portail actuel est une abomination qui est en train d'être remanié et je pense que le plan le plus rentable sera d'introduire une couche de modèle de domaine via Doctrine 2 et de mettre 99,9% de toute la logique de validation d'entreprise et d'entrée dans les modèles , éviscérant l'abomination jusqu'à ce qu'elle devienne une couche logique de vue et d'authentification squelettique.

Question

Pour tout spécialiste Drupal, cela semble-t-il une approche viable? Doctrine2 pourrait-il bien fonctionner avec Drupal ou la logique de niveau supérieur Drupal a-t-elle besoin d'une intégration beaucoup plus étroite aux données?

Nous avons fait quelques sites où nous avons connecté des systèmes externes à Drupal où les données devaient être conservées dans le système externe. C'est avec cela que je passe la plupart de mon temps à travailler.

Lorsque nous faisons cela, nous créons généralement un type de contenu pour "stub out" le contenu dans l'autre système. Le type de contenu contient uniquement le titre du nœud et un champ CCK pour l'identifiant unique dans l'autre système. Parallèlement à cela, il existe de nombreuses fonctions hook_nodeapi . Par exemple, le loadhook appellera le système distant et ajoutera les données au nœud. Vous devez également concevoir une méthode pour obtenir les données externes dans les résultats de recherche. Il existe quelques méthodes pour cela, mais elles sont trop longues pour entrer ici.

Bien qu'il y ait des inconvénients, nous trouvons que cela fonctionne bien et permet des choses Drupal normales comme les commentaires, les balises, etc.

La seule chose sensée à faire, étant donné le calendrier, est de le construire dans Drupal 7. L'une des fonctionnalités les plus importantes de Drupal 7, ce sont les entités, le DBNTG et les champs.

Un aperçu rapide

• Les entités est un moyen de définir une structure de données. Exemples d'entités intégrées à Drupal: nœuds (contenu principal), utilisateurs, termes de taxonomie.
• Les champs sont quelque chose qui peut être attaché à une entité, qui contient également des données. L'utilisation des champs a l'avantage de n'avoir qu'un seul endroit pour gérer les données et ils peuvent s'étendre de différentes manières. Un exemple de champ peut être une pièce jointe ou une référence à une autre entité.
• DBTNG (Database the next generation) est ce que la communauté Drupal avait nommé la nouvelle couche d'abstraction de base de données. Avant cela, nous faisions des requêtes avec des espaces réservés (qui sont toujours pris en charge), mais maintenant la plupart des requêtes sont construites avec classe. Une raison à cela est également que les champs obtiennent leurs tables de base de données créées en fonction des paramètres. Cela permet de créer du code qui fonctionnera, même si le ou les champs sont créés avec des paramètres différents.

Ce ne sont que quelques-unes des fonctionnalités, mais cela signifie qu'à moins que vous ne vouliez créer une abomination Drupal, vous devriez commencer à réfléchir au fonctionnement de Drupal et à l'utiliser au lieu d'essayer de faire fonctionner Drupal d'une manière qui n'a pas été conçue pour lui.

Puisque Drupal est PHP, vous pouvez créer des modules personnalisés et utiliser Doctrine2 pour faire ce que vous voulez. Mais je suppose que vous vous retrouverez avec un site qui a très peu en commun avec la plupart des sites Drupal.

Il s'agit d'une question assez large, je vais donc donner une réponse de haut niveau, si vous avez des questions plus spécifiques, posez-les en tant que questions distinctes.

Je vous suggère de cartographier autant que possible la structure du site actuel. Quels types de choses fait-il, quels sont les flux de travail. Quel est le contenu quels sont les utilisateurs.

Les types de contenu sont un moyen pratique de diviser le contenu. Même l'abomination aurait eu des types que je pense (j'aurais espéré) qui correspondent aux URL.

Une fois que vous avez déterminé les types de contenu, vous pouvez envisager de migrer le contenu vers votre nouveau site. Ensuite, vous pouvez regarder des choses comme les flux de travail, les horaires, les utilisateurs, etc.

Je préférerais déménager en gros. La gestion de contenu par plusieurs systèmes est un énorme casse-tête technique. Et double votre effort de maintenance.

Une chose que je dirais, c'est qu'il peut être utile d'engager quelqu'un pour le faire. Il y a eu quelques migrations Drupal très réussies avec d'énormes ensembles de données. Mais si vous n'êtes pas expérimenté dans Drupal, vous pouvez faire plusieurs erreurs et vous coûter beaucoup de temps. (Je peux personnellement recommander cyrve , je n'ai aucune affiliation actuelle avec eux)