Jak przenieść zainstalowane moduły z / witryn / wszystkich / modułów / * do / witryn / wszystkich / contrib / modułów / *

34

Poszukiwałam odpowiedzi na to pytanie bez powodzenia. Z tego, co obserwuję w strukturze bazy danych, położenie modułów jest określone w tabeli „systemowej”. Jedyne rozwiązanie, jakie mam, to napisanie zapytania SQL w celu zaktualizowania kolumny „nazwa pliku”.

Czy istnieje lepsze / czystsze rozwiązanie w rozwiązywaniu tego, na przykład dla modułu contrib?

Logi
źródło

Odpowiedzi:

27

Wystarczy przenieść moduły do ​​nowej lokalizacji i odbudować rejestrację. Gdy rejestr zostanie odbudowany, ścieżka do modułów zostanie zaktualizowana. Sprawdzić registry_rebuild().

Ponownie skanuje cały kod w modułach lub obejmuje katalogi, przechowując lokalizację każdego interfejsu lub klasy w bazie danych.

Chociaż zalecam wykonanie kopii zapasowej bazy danych przed przetestowaniem tego.

Jeśli korzystasz z drush, możesz również odbudować rejestr za pomocą następującego polecenia:

drush cc registry

Możesz także zainstalować registry_rebuildpolecenie dla drush:

// install registry_rebuild
drush dl registry_rebuild
// rebuild the registry
drush rr
Kod cyklonowy
źródło
Jeśli dobrze to rozumiem, możesz również obciąć swój registry_filestół, co zmusi Drupala do ponownego przeskanowania wszystkich plików i przebudowania stołu.
Cyclonecode
3
Obcinanie stołu wydaje się złym pomysłem i najprawdopodobniej doprowadzi do całkowicie zepsutej strony.
Berdir,
@Berdir - Zgadzam się, że to brzmi jak zły pomysł. Ale po prostu spróbowałem i wydaje się, że działa. Najpierw zrobiłem kopię zapasową i obciąłem cały stół, używając DELETE FROM registry_file;i dodałem wywołanie do rebuild_registry()mojego page.tpl.php.
Kod cyklonowy
To jest zbyt skomplikowane, po prostu rób to, co powiedział John Laine , to zawsze działało dla mnie.
Jim Kirkpatrick
1
@JimKirkpatrick - Masz rację, nie musisz wyłączać modułów.
Kod cyklonowy
10

Lokalnie przywróciłem kopię zapasową z produkcji i próbowałem po prostu przenieść rzeczy i uderzyć admin / moduły lub uruchomić register_rebuild (), ale nie powstrzymało to zgubnych błędów. Ma to dla mnie sens, ponieważ niektóre moduły mogą korzystać z funkcji include lub cokolwiek w ich funkcji hook_init (), lub możesz mieć zestaw ścieżek routera menu, który zależy od modułu lub włączenia, którego Drupal nie może znaleźć na bootstrapie. Ostatecznie to właśnie zrobiłem (twoje ścieżki mogą być inne):

Krok 1: Zamień strony / wszystkie / moduły na witryny / wszystkie / moduły / contrib

UPDATE system SET filename = REPLACE(filename, 'sites/all/modules', 'sites/all/modules/contrib');
UPDATE registry SET filename = REPLACE(filename, 'sites/all/modules', 'sites/all/modules/contrib');
UPDATE registry_file SET filename = REPLACE(filename, 'sites/all/modules', 'sites/all/modules/contrib');

Krok 2: Zamień strony / wszystkie / moduły / contrib na witryny / wszystkie / moduły / niestandardowe dla niestandardowych modułów z przestrzenią nazw

UPDATE system SET filename = REPLACE(filename, 'sites/all/modules/contrib', 'sites/all/modules/custom') WHERE name LIKE 'my_custom_namespace_%';
UPDATE registry SET filename = REPLACE(filename, 'sites/all/modules/contrib', 'sites/all/modules/custom') WHERE name LIKE 'my_custom_namespace_%';
UPDATE registry_file SET filename = REPLACE(filename, 'sites/all/modules/contrib', 'sites/all/modules/custom') WHERE filename LIKE '%my_custom_namespace_%';

Krok 3: Przenieś moduły deweloperskie na strony / all / modules / dev

UPDATE system SET filename = REPLACE(filename, 'sites/all/modules/contrib', 'sites/all/modules/dev') WHERE name LIKE 'devel%';
UPDATE registry SET filename = REPLACE(filename, 'sites/all/modules/contrib', 'sites/all/modules/dev') WHERE name LIKE 'devel%';
UPDATE registry_file SET filename = REPLACE(filename, 'sites/all/modules/contrib', 'sites/all/modules/dev') WHERE filename LIKE '%devel%';

Krok 4: Wyczyść pamięć podręczną, aby elementy poprawnie się ładowały

TRUNCATE TABLE cache
TRUNCATE TABLE cache_bootstrap
TRUNCATE TABLE cache_menu
TRUNCATE TABLE cache_page
TRUNCATE TABLE cache_path

Uwaga: Jeśli używasz niestandardowego modułu lub wkładu, takiego jak LoginToboggan do obsługi 403 (odmowa dostępu) i wylogowałeś się podczas tego procesu, może być konieczne zaktualizowanie include_filekolumny w menu_rotertabeli, aby użyć nowej ścieżki do pliku dołączania . Jest to prawdopodobnie rzadkie zjawisko.

UPDATE menu_router SET include_file = 'sites/all/modules/custom/my_custom_namespace/includes/foo.inc' WHERE path = 'access-denied'

Po uruchomieniu tych zapytań - co zajmie tylko ułamek sekundy - kliknij admin / config / development / performance i wyczyść pamięć podręczną, aby odbudować ścieżki menu.

Charlie Schliesser
źródło
Dzięki za to! Próbowałem kroków wymienionych w najważniejszych odpowiedziach, ale to nie pomogło w moim przypadku. Podejrzewam, że każdy na stronie hostowanej przez Panteon musi wykonać te instrukcje db w twojej odpowiedzi, a następnie wykonać „drush rejestru-rebuild” i „drush cc register”
Anne Bonham
No i na Panteonie nie mogłem znaleźć strony z modułem Redis nigdzie poza witrynami / wszystkimi / modułami - więc po prostu poddałem się i zostawiłem ten moduł w folderze modułów głównych. No cóż - przynajmniej inne moje moduły są ładnie zorganizowane.
Anne Bonham,
Dla tych, którzy używają LoginToboggan, oto 3 polecenia MySQL, których potrzebujesz:update menu_router set include_file = 'sites/all/modules/contrib/logintoboggan/logintoboggan.admin.inc' WHERE path = 'admin/config/system/logintoboggan'; update menu_router set include_file = 'sites/all/modules/contrib/logintoboggan/logintoboggan.validation.inc' WHERE path = 'toboggan/revalidate/%'; update menu_router set include_file = 'sites/all/modules/contrib/logintoboggan/logintoboggan.validation.inc' WHERE path = 'user/validate/%/%/%';
tyler.frankenstein 30.04.2018
7

Dla przypomnienia, istnieje świetne polecenie drush do odbudowania rejestru: http://drupal.org/project/registry_rebuild

Na stronie projektu znajduje się mnóstwo informacji.

jonhattan
źródło
To moja najbardziej preferowana metoda przenoszenia modułów. Miałem włączone moduły, w sites/all/modulesktórych trzeba było przenieść do contribpodkatalogu. Wszystko, co musiałem zrobić, todrush dl registry_rebuild; mv OLD_PATH/module NEW_PATH/module; drush rr
Sumeet Pareek,
To zadziałało dla mnie. Najpierw przeniosłem wszystkie moje moduły, a potem zrobiłem
register_rebuild
Co ciekawe, drush rr --fire-bazookaprowadzi do błędów, ale drush rrjest w porządku.
Alex Skrypnyk
5

Po pierwsze zawsze wykonuj kopię zapasową bazy danych, tak proste, że wykopiesz się, jeśli coś pójdzie nie tak i nie wykonałeś kopii zapasowej.

Nie jestem pewien, czy to ważne, czy wyłączysz moduły, czy nie; na wszelki wypadek możesz to zrobić. Następnie zrób to:

  1. Przełącz swoją witrynę w tryb konserwacji pod adresem (nazwa pliku) / admin / config / development / Maintenance
  2. Fizycznie przenieś moduły w systemie plików.
  3. Wyczyść pamięć podręczną pod adresem (nazwa_ sit) / admin / config / development / performance lub po prostu ponownie zapisz stronę modułów.

Wszystko gotowe! Drupal ponownie przeszuka wszystkie zainstalowane moduły.

John Laine
źródło
+1 za tryb utrzymania, zawsze miło to zrobić przed czymś takim
Cyclonecode
1
To powoduje dla mnie błędy krytyczne w 100% przypadków. Może to działa, jeśli przenosisz moduły, które nie mają zależności lub czegoś takiego.
ergophobe
4

Dlaczego nie wypróbować modułu Odbudowa rejestru? To działało dla mnie za każdym razem.

Oto cytat na ten temat (ze strony projektu modułu):

W Drupal 7 są chwile, kiedy rejestr zostaje beznadziejnie ukryty i trzeba go odbudować (listę klas PHP i plików, z którymi się łączą). Czasami jednak nie można wykonać tej zwykłej czynności czyszczenia pamięci podręcznej, ponieważ podczas próby uruchomienia systemu wymagana jest pewna klasa.

drupalastyczny
źródło
Chociaż teoretycznie może to odpowiedzieć na pytanie, lepiej byłoby zawrzeć tutaj istotne części odpowiedzi i podać odnośnik. Jeśli istnieje procedura przenoszenia modułów, która obejmuje użycie modułu, który podłączyłeś, opisz to.
Mołot
Żadna teoria ... to działa. Postępuj zgodnie z instrukcjami na stronie. Użyłem metody drush i po prostu zadziałało.
iLLin
3

Możesz użyć modułu Registry Rebuild , który integruje się z Drush za pośrednictwemDrush RR polecenia.

Zasadniczo wykonujesz następujące kroki:

  1. Przenieś moduły do ​​innego katalogu i
  2. Registry Rebuild odbuduje następnie tabelę systemową, aby moduły znalazły się we właściwym miejscu.

Po raz pierwszy nauczyłem się go / odkryłem poprzez DrupalEasy Podcast # 133 , który wyjaśnia, jak można używać tego modułu / cmd drush.

PS: Oczywiście najpierw wykonaj kopię zapasową witryny ...

Pierre.Vriens
źródło
3
Popieram to. Utwórz kopię zapasową witryny. Przenieś wszystkie moduły do ​​nowych folderów. Uruchom przebudowę rejestru w drush lub po prostu postępuj zgodnie z instrukcjami i przejdź do dołączonego pliku php, aby go uruchomić. Prosty.
Collins,
2

Odwiedź / admin / build / modules przebuduje ścieżki w tabeli systemowej. Czasami drupal nie może już uruchomić systemu, więc to rozwiązanie nie działa w tym przypadku. Jeśli to nie działa, możesz użyć Drush Rebuild Project Paths, jak powiedziano w poprzedniej odpowiedzi. Musisz jednak dodać nowe polecenie drush przed zerwaniem bootstrapu. Aby dodać nowe polecenie, sprawdź sekcję POLECENIA w pliku readme

Zatox
źródło
2

Miałem pewne problemy z niedziałaniem z drush dlpowodu problemów z katalogiem modułów. Zasadniczo lubię stosy odpowiedzi, które mogę po prostu wkleić, aby wszystko działało. Tutaj znajdziesz kilka wierszy, które zainstalują Rejestr Drush Rebuild i uruchomią go na twojej stronie, jeśli jesteś już w odpowiednim katalogu witryny.

pushd ~  # good if drush on your site is broken because of moved modules
drush dl -y registry_rebuild
popd 
drush rr
finanse fifi
źródło
2

Nie jestem w 100% pewien prawdziwej odpowiedzi na drupal-esk, ale z mojego doświadczenia:

Przypadkowo przeniosłem jeden z moich niestandardowych folderów modułów do innego niestandardowego folderu modułów podczas przesyłania FTP na serwer. Oboje nadal pracowali. Drupal wydawał się rozpoznawać go jako oddzielny moduł, nawet gdy znajdował się w folderze innego modułu. Nie musiałem wyłączać modułu.

** Ten moduł, który przeniosłem, NIE miał pliku .install, więc nie jestem pewien, czy to ma znaczenie.

Exziled
źródło
Plik instalacyjny dotyczy tylko procedur wywoływanych podczas instalacji modułu i nie jest wymagany. Działało, ponieważ możesz mieć dowolną strukturę folderów w / sites / all / modules, drupal będzie rekurencyjnie szukał plików .info.
gbyte.co,
@ gbyte.co dziękuję za wyjaśnienie na ten temat! Wiedziałem o pliku instalacyjnym, ale nie znałem rekurencyjnego procesu drupala w poszukiwaniu plików .info. Uznałem, że nie ma znaczenia, w którym podfolderze są, ale dobrze jest mieć solidną odpowiedź!
Exziled
1

Dystrybucje Drupal nie radzą sobie tak dobrze, więc ostatnio po przypadkowym skończeniu z kopią API Entity wsites/all/ na miejscu Panopoly, żaden z tym pracował. Odbudowa rejestru, ładowanie strony modułów i wszystko inne spowodowało błąd krytyczny.

Wyłączenie modułu nie jest proste, jeśli musisz przenieść coś takiego jak Entity API, który jest wymagany przez mnóstwo innych modułów w Panopoly.

Aby rozwiązać ten problem, dla interfejsu API Entity zrobiłbyś coś takiego:

  1. Zaktualizuj ścieżkę w tabeli systemowej:

    UPDATE `system` 
      SET `filename` = REPLACE(
        `filename`, 
        'sites/all/modules/entity', 
        'profiles/panopoly/modules/contrib/entity'
      );
  2. Następnie odbuduj rejestr:

    drush rr
ergofob
źródło
1

Drupal 7

Po pierwsze spróbuj drush rr .

Jeśli to nie zadziała, po przeniesieniu plików wypróbuj następujące polecenia Drush w katalogu głównym Drupal:

drush sqlq "TRUNCATE cache; TRUNCATE cache_bootstrap;"
php -r "define('DRUPAL_ROOT', getcwd()); require_once DRUPAL_ROOT . '/includes/bootstrap.inc'; drupal_bootstrap(DRUPAL_BOOTSTRAP_SESSION); registry_rebuild(); registry_update(); cache_clear_all();"
drush -y cc all

Jeśli powyższe nie działa, znajdź tabelę, która nadal zawiera starą informację o ścieżce:

drush --ordered-dump sql-dump | grep "sites/all/modules" # Change the path to the old one.

Jeśli nie zostanie znaleziony, oznacza to, że jest to twoja zewnętrzna pamięć podręczna.

Jeśli tak, nie zapomnij ich ponownie uruchomić, np .:

killall -HUP memcached
drush eval "function_exists('xcache_clear_cache') && xcache_clear_cache();"

Zobacz więcej: Jakiej metody używa się do usuwania pamięci podręcznych w Drupal?


Alternatywnie możesz spróbować następujących zapytań MySQL po przeniesieniu plików:

UPDATE system SET filename = REPLACE(filename, "sites/all/modules", "sites/newplace/modules") WHERE
       filename LIKE "sites/all/modules/%" AND type = "module"
       AND name IN ("my", "module", "whose", "path", "changed");

UPDATE registry SET filename = REPLACE(filename, "sites/all/modules", "sites/newplace/modules") WHERE
       filename LIKE "sites/all/modules/%"
       AND module IN  ("my", "module", "whose", "path", "changed");
kenorb
źródło
1

Zalecane jest przeniesienie modułów do podfolderów contrib / dev / patched / custom. Jednak nie ma wzrostu wydajności, dzieje się tak ze względów praktycznych i estetycznych. Ułatwi to życie przyszłym programistom.

Możesz przenieść większość modułów contrib do podfolderów bez problemu na aktywnej stronie. Następnie powinieneś wyczyścić skrzynki. Jeśli nie użyjesz drush i okaże się, że nie możesz już uzyskać dostępu do strony czyszczenia pamięci podręcznej, będziesz musiał odwiedzić /update.php lub ręcznie obciąć tabele pamięci podręcznej. Ostatni raz musiałem zrobić ostatni bit podczas przenoszenia modułu API encji.

Przeniesienie modułów podstawowych jest technicznie możliwe, ale nie poleciłbym tego ani nie widzę żadnego uzasadnionego powodu, aby to zrobić.

Aktualizacja: Przenoszenie modułów, takich jak API encji, może wymagać odbudowania rejestru. Sprawdź stronę Registry_rebuild .

gbyte.co
źródło
-4

Możesz po prostu dodać link sym w katalogu sites / all / modules wskazujący na sites / all / contrib. Nie jestem pewien, czy to rozwiąże twój problem. Istnieją również inne rozwiązania, w tym profil instalacyjny lub plik drush make. Nie wiem wystarczająco, aby podać szczegółowe informacje na ich temat, ale przynajmniej jest to kierunek, na który można spojrzeć.

leksykant
źródło
5
Na dłuższą metę jest to ból głowy związany z utrzymaniem
AgA,
to jest hack i omija poprawkę ... niezbyt dobre rozwiązanie.
iLLin
o wiele lepiej jest używać drush register_rebuild teraz, gdy jest dostępny.
leksykant