Bonjour,
J’ai une question pour les «informés» du développement Drupal, au sujet de l’avenir du CCK, et de la façon dont il va être introduit dans le coeur de Drupal 7.
En l’état actuel de la version de développement, il n’est introduit qu’en partie et il faut tout de même charger le module additionnel pour bénéficier de plus de champs (nodereference..). Soit. L’organisation des tables est modifiée et au lieu d’avoir des tables content_ avec notamment des content_type_nomdutype contenant les valeurs, pour chaque noeud, des champs persos (le title et le body étant contenus dans la node_revisions), on a des tables field_ et les données sont dans une table field_data_nomduchamp. Soit.
Pas de problème pour créer de nouveaux champs et de nouveaux types de contenus.
Mégaproblème, en revanche, pour les champs custom des types de contenus existant. Drupal ne va plus chercher les données dans les tables content_type_ et les noeuds ne sont plus qu’un titre et, éventuellement, un body.
Ma question est double :
- ce problème est-il lié au fait que D7 n’est encore que balbutiant, et peut-on m’assurer que les données enregistrées dans les tables content_machinchose seront toujours récupérables ?
- comment cela va-t-il se passer dans le cas où les tables content_ sont préfixées de façon sélective (càd pas de préfixe par défaut car partage de certains paramètres entre plusieurs sites mais content_ préfixées car contenu impérativement distinct), par un array( dans le settings.php ? Les nouvelles tables field_ se retrouvent non préfixées, du coup le contenu ultérieur des différents sites sera mélangé dans les même tables, ce qui m’est interdit…
Quid ???
Merci,
- Vous devez vous identifier ou créer un compte pour écrire des commentaires
D7 étant encore en développement, rien n’est prêt pour le moment à ce sujet, mais à terme l’upgrade des champs et données CCK D6 vers ‘Fields in core’ D7 sera bien entendu pris en charge de manière automatique. Il est hors de question de livrer D7 en disant ‘tant pis pour vos champs CCK D6’ :-)
La forme exacte que cela va prendre n’est pas encore définie précisément, la question commence à être discutée sur http://drupal.org/node/366364.
A priori je ne vois pas de raison qui ferait que les tables préfixées pour du multisite poseraient un problème particulier. Chaque site a son préfixe et connait quelles tables il utilise. C’est géré par l’API drupal ; pour les modules et les scripts d’upgrade, c’est transparent.
yched@drupal.org
104
Bonjour,
Merci pour la réponse ; pour la récupération des données du CCK , j’imaginais bien qu’une solution était prévue (ç’aurait été un peu énorme !) mais ce changement de structure m’inquiète un peu pour l’avenir du projet sur lequel je travaille. Je vais suivre la discussion à laquelle tu me renvoies. S’agissant du préfixe, le problème vient de ce que que je pens(ais) utiliser un «non préfixage par défaut» ; du coup lors de la création de nouvelles tables (les field_ par exemple), elles ne sont pas préfixées et les sites ne sont plus autonomes sur ces nouveaux modules. Cela signifie vraisemblablement qu’il faut que j’envisage l’inverse (préfixage par défaut), même si cela gonfle le settings.php de toutes les tables partagées.
Bref. C’est pas gagné c’t’histoire…
Merci pour les indications.
On n’est ni derrière votre dos, ni dans votre tête ! Soyez précis !
DRUPALISTIC : des infos sur Drupal et les modules. Sur twitter, 3 listes à suivre
Marie-Hélène
2068
Si le site D6 en question a des modules customs qui font directement des requètes sur les tables de données CCK, des modifications du code seront nécessaires lors du passage D6 -> D7.
Les Views basées sur des champs CCK devraient être pour une large part converties automatiquement, mais il est encore un petit peu tôt pour dire quoi que ce soit sur Views D7…
Je ne vois pas vraiment d’autres points qui devraient affecter la migration D6 -> D7.
Pour la question que tu abordes sur les préfixes, il s’agit d’un point existant sur CCK D6, et qui ne me parait pas réellement lié à la problématique d’une migration D6 -> D7, non ?
yched@drupal.org
104
Pour la question que tu abordes sur les préfixes, il s’agit d’un point existant sur CCK D6, et qui ne me parait pas réellement lié à la problématique d’une migration D6 -> D7, non ?
Sans doute pas directement, mais je n’ai jamais «vécu» d’autres grosses migrations comme celle-là, j’ai connu Drupal en septembre ou octobre dernier, donc toujours travaillé sous D6. Je travaille sur un projet à très long terme, donc avant de savoir si l’on retient Drupal pour ce projet j’essaie de faire un peu le tour des problèmes qui peuvent se poser. Et quand un problème apparait, je ne vois pas tout de suite à quoi il se rattache directement. Pour les préfixes, mon problème est dans les complications qu’ils peuvent poser à la migration D6->D7 car ce n’est sans doute pas moi-même qui m’occuperai de cette migration. C’est la raison pour laquelle je le rattache à la migration - peut-être à tort…
On n’est ni derrière votre dos, ni dans votre tête ! Soyez précis !
DRUPALISTIC : des infos sur Drupal et les modules. Sur twitter, 3 listes à suivre
Marie-Hélène
2068
une migration est-elle forcément obligatoire dans tous les cas de figure ? Je pense qu’il est mieux de migrer évidemment mais le principe ne «ne pas toucher à une application qui marche» me parait bon aussi ; ce n’est pas parce que le php passe de 4 à 5 qu’il faut obligatoirement recoder toutes ces applications en php5 si ça marche en php4 (pour donner un exemple parallèle à drupal)…
Ce n’est qu’une idée qui me passe par la tête mais j’avais déjà réfléchi à tout ça à cause d’un CMS qui s’appelle modx et donc le passage à la prochaine version va s’avérer radical. Ma conclusion étant que cela ne m’empecherait pas d’utiliser la version actuelle de modx de façon pérenne sur un projet tant que la sécurité n’est pas en cause et que le CMS dans cette version est efficace, même si cela implique que je ne migrerais jamais le projet sur le fameux modxrevolution…
C’était juste une réflexion en passant, peut être que c’est idiot.
http://formation.ideia.fr/formation/drupal-la-carte | http://twitter.com/nyl_auster
nyl auster
838