"La base de données source ne contient pas de version Drupal reconnaissable."

J'ai installé deux sites Drupal dans mon environnement local Ubuntu desktop 15.10 Apache2 (2.4.12): l'un est une nouvelle installation de Drupal 8 et le second est une copie d'un site de travail existant construit avec Drupal 7 (qui est principalement des modules de base). basé, très humble au moyen de pages). Les deux sites fonctionnent bien sans aucun problème, n'importe où.

Mon objectif est avant tout de mettre à niveau le site Drupal 7 vers Drupal 8. J'ai fait toutes les étapes préliminaires comme la configuration des mêmes langues, rester minimal au moyen de modules (désinstaller tous les modules du site D7 que je pourrais facilement ramener après la mise à niveau ), en m'assurant que les mêmes modules sont installés sur les deux sites, etc., et maintenant je veux juste "Transcender" (j'espère que c'est une bonne formulation) mon site Drupal 7 en un nouveau Drupal 8.

Pour atteindre mon objectif, j'ai installé le module de mise à niveau Drupal dans mon site Drupal 8, je suis allé à localhost / sitename / upgrade et j'ai rempli tous les détails du site Drupal 7.

Lorsque j'ai cliqué sur le bouton "Vérifier la mise à niveau", j'ai eu l'erreur:

La base de données source ne contient pas de version Drupal reconnaissable.

J'ai googlé cette erreur en tant que phrase exacte ("Erreur") et trouvé très peu de résultats; La plupart d'entre eux me semblent nécessiter une connaissance en programmation PHP que j'ai encore acquise, donc je ne peux pas déterminer si l'erreur est due à un bogue (d'autant plus que ce module est encore en développement) ou à cause de mon erreur dans comprendre le concept \ la fonctionnalité de ce module.

1. Quelles sont les raisons pour lesquelles le module de mise à niveau D8 Drupal "n'aimera" pas la base de données D7 que j'ai fournie? Surtout pendant que le site Drupal 7 fonctionne bien en ligne et localement.

2. La migration serait-elle une alternative décente pour la mise à niveau, si la mise à niveau n'est pas possible pour une raison quelconque? Si oui, quelle est la meilleure solution la plus simple à laquelle vous pourriez penser pour la migration?

Je suis allé sur /var/www/html/benia/modules/migrate_upgrade/src/MigrationCreationTrait.php et j'ai fait:

-- return $version_string ? substr($version_string, 0, 1) : FALSE;

++ return 7;
++ return $version_string ? substr($version_string, 0, 1) : FALSE;

Que obtenu cette erreur en haut de l'écran.

À ce stade, je ne pense pas qu'il existe une simpleoption pour passer de 7 à 8. Comme vous pouvez le voir sur la note de version:

Une fois que vous êtes prêt, Drupal 8 core comprend également le module Migrate pour mettre à jour directement les sites Drupal 7 et 6 existants vers Drupal 8. Migrate est marqué «expérimental» dans Drupal 8.0.0, mais sera entièrement pris en charge dans une prochaine version. https://www.drupal.org/news/drupal-8.0.0-released

Un peu technique en coulisse: de la version 7 à la version 8, ils gardent le même concept lors de la construction du site (comme nœud, entité, permission, vues ...) mais pas le cœur. Je dirais: ils ont tout changé en OOP, composant Symfony, architecture ... Donc, il n'y a aucun moyen d' upgradeaccéder directement à votre site drupal d'une version décente à 8.0, vous devez migrate. Voici à quoi migratingdevrait ressembler le processus:

1. Recréez le site avec les mêmes fonctionnalités sur votre site d7.
2. Recréez le thème (en utilisant le modèle de brindille)
3. Migrer du contenu sur

Le coût de ce processus est (malheureusement) le même pour recréer un nouveau site ou plus. Avec le n ° 3, jetez un œil à cet article de Phase 2: https://www.phase2technology.com/blog/upgrading-to-a-drupal-8-site/

Votre message d'erreur correspond exactement à la chaîne contenue dans la ligne à http://cgit.drupalcode.org/migrate_upgrade/tree/src/MigrationCreationTrait.php#n40 dans le code du module "Drupal Upgrade" ( https: / /www.drupal.org/project/migrate_upgrade ).

Cela montre qu'il ne s'agit pas d'un bug, mais plutôt d'une "exception levée". En regardant les 3 lignes précédentes de ce code, je pense que ce n'est qu'un problème dans la configuration de la connexion.

Peut-être que cela aide aussi:

• une citation du numéro https://www.drupal.org/node/2628440 (commentaire n ° 3):

  Pour vérifier que la base de données source est une base de données Drupal valide et pour déterminer la version de la base de données, le processus de mise à niveau examine la table «système» - cette table est-elle présente dans la base de données que vous avez spécifiée dans le formulaire? L'installation Drupal dans cette base de données est-elle préfixée (et si oui, avez-vous entré le préfixe dans la section "Options avancées" du formulaire)? ".

• Suivi du commentaire n ° 4 dans le même numéro: "La fourniture du préfixe des tables a résolu le problème.".

Et bien sûr, le commentaire de benjy (merci!) Aiderait également à obtenir plus de détails sur l'erreur réelle que vous rencontrez, à savoir:

vous pouvez imprimer $ e-> getException () ici cgit.drupalcode.org/migrate_upgrade/tree/src/… et ensuite vous verrez l'erreur PDO

Vous pouvez (temporairement) ajouter une telle impression entre les lignes 122 et 123 dans le code affiché via le lien.

Au moment où vous forcez la base de code à ignorer la lecture de {system}, elle meurt en ne trouvant pas la prochaine table de base de données, {field_config_instance}. En d'autres termes: il ne lit pas votre base de données D7. Peut-être qu'il essaie de lire le D8, peut-être quelque chose de totalement différent, comment pourrions-nous savoir? Il est plus que probable que vous entrez une mauvaise configuration de base de données (par exemple, les deux sites sont sur des serveurs différents avec le serveur mysql étant localhost sur les deux mais localhost n'est pas le même serveur). Je viens de vérifier le module contrib Migrate Upgrade et le code du module de migration de base à la fois et il serait extrêmement surprenant qu'il y ait un bogue relatif au préfixe car les deux gèrent un tableau complet de paramètres de base de données, pas pièce par pièce.

Il est impossible de dire sans avoir accès à votre infra sur la façon de résoudre ce problème. Désolé. Si je le pouvais, je voterais pour le fermer, mais comme il y a une prime, je ne peux pas. Nous ne pouvons pas vous aider et cette question n'aidera personne. La seule aide possible est la suivante: lisez et comprenez votre fichier de paramètres Drupal 7 et donnez les bonnes informations d'identification au module Migrate Upgrade (la grande quantité de commentaires montre déjà que cela ne va nulle part.)

Une solution à plus long terme pourrait inclure une fonctionnalité dans le module contrib où les gens peuvent télécharger leur settings.php et nous pourrions ensuite essayer de l'utiliser. C'est extrêmement fragile mais ça vaut le coup je suppose. Quand quelqu'un aura le temps de le coder ...

Je n'ai aucune idée pourquoi les gens ont voté si fortement. Y a-t-il quelqu'un d'autre qui a le même problème?

Beaucoup de temps s'est écoulé depuis que j'ai posté cela, mais je pense que je sais maintenant quel était le problème:

J'ai laissé 2 à 3 modules installés, ce que je pensais (alors) être "si basique", donc j'étais sûr qu'ils avaient un chemin de migration comme tous les modules de base.

Ceux-ci étaient, si je me souviens bien: Metatag et Redirect (vous passez de D7 Globalredirect & Redirect à seulement Rediriger dans Drupal 8).

Non seulement je les ai laissés sur le site D7, mais je les ai également installés dans le D8, donc aucune des versions de mon site n'était réservée au noyau, selon les besoins.

C'était ma première migration et j'ai fait cette erreur en tant que débutants au projet. J'étais vraiment convaincu que «cela ne peut pas être» que ces modules n'auront pas de chemin de migration (et quand vous y pensez, ils devraient vraiment avoir), mais j'ai découvert qu'en effet, généralement seuls les modules de base ont et rien sinon devrait avoir un chemin de migration personnalisé ou contrib.

Juste pour que vous sachiez --- Ces modules et d'autres ont des chemins de migration contrib que vous pouvez utiliser en les corrigeant avec ce chemin de migration (vous "l'injectez" dans le module avec le chemin).

Quoi qu'il en soit, ce n'était pas le cas pour moi à l'époque et j'étais sûr qu'il est livré avec le système ...

J'avais douloureusement tort et cela me semble être la seule raison pour laquelle la migration ci-dessus a échoué; J'ai même renforcé cette hypothèse avec une petite expérience que j'ai faite avant ma dernière migration réussie il y a environ 2 mois.

Une fois que j'ai reçu ce message d'erreur. Il s'est avéré être le $ db_prefix défini par moi "drupal_". Vous devriez mettre cela dans les options avancées.

Cordialement, Carlos Aleman