„Źródłowa baza danych nie zawiera rozpoznawalnej wersji Drupal”.

Zainstalowałem dwie witryny Drupal w moim lokalnym środowisku Ubuntu Desktop 15.10 Apache2 (2.4.12): Jedna to nowa instalacja Drupala 8, a druga to kopia istniejącej działającej strony zbudowanej z Drupala 7 (która jest w większości modułami podstawowymi oparty, bardzo skromny za pomocą stron). Obie strony działają dobrze bez problemu, gdziekolwiek.

Moim celem jest przede wszystkim uaktualnienie witryny Drupal 7 do Drupal 8. Zrobiłem wszystkie wstępne etapy, takie jak konfiguracja tych samych języków, Utrzymanie minimalnego poziomu za pomocą modułów (odinstalowanie modułów w witrynie D7, które można łatwo przywrócić po aktualizacji ), upewniając się, że te same moduły są zainstalowane w obu witrynach itp., a teraz chcę po prostu „Transcendować” (mam nadzieję, że to dobre sformułowanie) mojej witryny Drupal 7 do nowej wersji Drupal 8.

Aby osiągnąć mój cel, zainstalowałem moduł aktualizacji Drupal na mojej stronie Drupal 8, poszedłem do localhost / sitename / upgrade i wypełniłem wszystkie szczegóły strony Drupal 7.

Kiedy kliknąłem przycisk „Sprawdź aktualizację”, dostałem błąd:

Źródłowa baza danych nie zawiera rozpoznawalnej wersji Drupal.

Znalazłem ten błąd jako dokładną frazę („Błąd”) i znalazłem bardzo niewiele wyników; Wydaje mi się, że większość z nich wymaga znajomości programowania PHP, którą już zdobyłem, więc nie mogę ustalić, czy błąd jest spowodowany błędem (zwłaszcza, że ​​ten moduł jest wciąż w fazie rozwoju), czy też z powodu mojego błędu w zrozumienie koncepcji \ funkcjonalności tego modułu.

1. Jakie są powody, dla których moduł aktualizacji D8 Drupal nie „polubi” bazy danych D7, którą dostarczyłem? Zwłaszcza, gdy strona Drupal 7 działa dobrze zarówno online, jak i lokalnie.

2. Czy migracja byłaby przyzwoitą alternatywą dla aktualizacji, jeśli aktualizacja z jakiegokolwiek powodu nie jest możliwa? Jeśli tak, jakie jest najprostsze rozwiązanie, o którym możesz pomyśleć o migracji?

Poszedłem do /var/www/html/benia/modules/migrate_upgrade/src/MigrationCreationTrait.php i zrobiłem:

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

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

Ten błąd pojawił się w górnej części ekranu.

Na tym etapie nie sądzę, aby istniała simpleopcja aktualizacji z 7 na 8. Jak widać w informacji o wydaniu:

Gdy będziesz gotowy, rdzeń Drupal 8 zawiera również moduł Migruj do bezpośredniej aktualizacji istniejących witryn Drupal 7 i 6 do Drupal 8. Migracja jest oznaczona jako „eksperymentalna” w Drupal 8.0.0, ale będzie w pełni obsługiwana w nadchodzącym wydaniu. https://www.drupal.org/news/drupal-8.0.0-released

Trochę techniczne za kulisami: od wersji 7 do 8 zachowują tę samą koncepcję podczas budowy witryny (jak węzeł, jednostka, pozwolenie, widoki ...), ale nie rdzeń. Powiedziałbym: zmienili wszystko na OOP, komponent Symfony, architekturę ... Więc nie ma sposobu na upgradetwoją stronę drupal bezpośrednio z przyzwoitej wersji na 8.0, musisz migrate. Oto jak migratingpowinien wyglądać ten proces:

1. Odtwórz witrynę z tą samą funkcjonalnością, co w witrynie d7.
2. Utwórz ponownie motyw (używając szablonu gałązki)
3. Przeprowadź migrację treści

Koszt tego procesu jest (niestety) taki sam, aby odtworzyć nową witrynę lub więcej. W przypadku numeru 3 zapoznaj się z tym artykułem w fazie 2: https://www.phase2technology.com/blog/upgrading-to-a-drupal-8-site/

Twój komunikat o błędzie jest dokładnie zgodny z ciągiem zawartym w wierszu na stronie http://cgit.drupalcode.org/migrate_upgrade/tree/src/MigrationCreationTrait.php#n40 w kodzie modułu „Drupal Upgrade” ( https: / /www.drupal.org/project/migrate_upgrade ).

Pokazuje, że nie jest to błąd, ale „zgłoszony wyjątek”. Patrząc na 3 poprzednie wiersze tego kodu, myślę, że jest to tylko problem z konfiguracją połączenia.

Może to pomaga również:

• cytat z wydania https://www.drupal.org/node/2628440 (komentarz nr 3):

  Aby sprawdzić, czy źródłowa baza danych jest prawidłową bazą danych Drupal, i aby określić wersję bazy danych, proces aktualizacji sprawdza tabelę „systemową” - czy ta tabela jest obecna w bazie danych określonej w formularzu? Czy instalacja Drupal w tej bazie danych ma prefiks (a jeśli tak, to czy wpisałeś prefiks w sekcji „Opcje zaawansowane” formularza)? ”.

• Następnie komentarz nr 4 w tym samym numerze: „Podanie prefiksu tabel rozwiązało problem.”.

I oczywiście komentarz Benjy (dziękuję!) Pomógłby również uzyskać więcej szczegółów na temat rzeczywistego błędu, na który napotykasz , tj .:

możesz wydrukować $ e-> getException () tutaj cgit.drupalcode.org/migrate_upgrade/tree/src/... i wtedy zobaczysz błąd PDO

Możesz (tymczasowo) dodać taki wydruk między wierszami 122 i 123 w kodzie wyświetlanym za pośrednictwem łącza.

W chwili wymuszenia, aby baza kodów pominęła czytanie {system}, umiera, nie znajdując następnej tabeli bazy danych {field_config_instance}. Innymi słowy: nie czyta bazy danych D7. Może próbuje odczytać D8, może coś zupełnie innego, skąd możemy wiedzieć? Bardziej niż prawdopodobne, że wprowadzasz niewłaściwą konfigurację bazy danych (powiedzmy, że dwie witryny znajdują się na różnych serwerach, a serwer mysql jest hostem lokalnym na obu, ale host lokalny nie jest tym samym serwerem). Właśnie sprawdziłem oba moduły programu Migrate Upgrade i kod modułu migrującego rdzeń, i byłoby bardzo zaskakujące, gdyby wystąpił błąd związany z prefiksem, ponieważ oba obsługują całą tablicę ustawień bazy danych, a nie kawałek po kawałku.

Nie można powiedzieć bez dostępu do infra, jak to naprawić. Przepraszam. Gdybym mógł, głosowałbym za jego zamknięciem, ale ponieważ jest nagroda, nie mogę. Nie możemy ci pomóc, a to pytanie nie pomoże innym. Jedyną możliwą pomocą jest to: przeczytaj i zrozum plik ustawień Drupal 7 i podaj odpowiednie dane uwierzytelniające modułowi Migrate Upgrade (ogromna liczba komentarzy już pokazuje, że to nie zmierza).

Jednym z możliwych długoterminowych rozwiązań byłaby funkcja w module contrib, w której ludzie mogą przesyłać swoje settings.php, a następnie moglibyśmy spróbować z nich skorzystać. Jest to wyjątkowo delikatne, ale chyba warte strzału. Kiedy ktoś będzie miał czas na kodowanie ...

Nie mam pojęcia, dlaczego ludzie tak mocno go głosowali. Czy jest jeszcze ktoś, kto ma ten sam problem?

Minęło dużo czasu, odkąd to opublikowałem, ale myślę, że teraz wiem, jaki był problem:

Pozostawiłem zainstalowane 2-3 moduły, które (wtedy) uważałem za „tak podstawowe”, więc byłem pewien, że mają ścieżkę migracji, tak jak wszystkie moduły podstawowe.

Były to, o ile dobrze pamiętam: Metatag i Przekierowanie (przechodzisz z D7 Globalredirect & Redirect do samego przekierowania w Drupal 8).

Nie tylko zostawiłem je w witrynie D7, ale także zainstalowałem je w D8, więc żadna z wersji mojej witryny nie była przeznaczona tylko dla rdzenia, w razie potrzeby.

To była moja pierwsza migracja i popełniłem ten błąd jako początkujący projekt. Byłem naprawdę przekonany, że „nie może być”, że te moduły nie będą miały ścieżki migracji (a jeśli się nad tym zastanowić, to naprawdę powinny), ale potem odkryłem, że rzeczywiście, zwykle tylko moduły podstawowe mają i cokolwiek w przeciwnym razie powinna mieć niestandardową ścieżkę migracji.

Po prostu wiesz --- Te i inne moduły mają ścieżki migracji contrib, których możesz użyć, łatając je tą ścieżką migracji („wstrzykujesz” ją do modułu ścieżką).

W każdym razie tak nie było w moim przypadku i byłem pewien, że pochodzi z systemem ...

Boleśnie się pomyliłem i wydaje mi się, że to jedyny powód niepowodzenia migracji; Potwierdziłem to założenie nawet małym eksperymentem, który przeprowadziłem przed ostatnią udaną migracją około 2 miesięcy temu.

Po otrzymaniu tego komunikatu o błędzie. Okazało się, że to $ db_prefix ustawiony przeze mnie „drupal_”. Powinieneś umieścić to w opcjach zaawansowanych.

Pozdrawiam, Carlos Aleman