설치된 모듈을 / sites / all / modules / *에서 / sites / all / contrib / modules / *로 이동하는 방법

나는이 질문에 대한 답을 전혀 운없이 찾지 못했습니다. 데이터베이스 구조에서 관찰 한 것부터 모듈 위치는 '시스템'테이블에 지정되어 있습니다. 내가 가진 유일한 해결책은 'filename'열을 업데이트하기 위해 SQL 쿼리를 작성하는 것입니다.

예를 들어 contrib 모듈과 같이이 문제를 해결하는 데 더 나은 / 더 깨끗한 솔루션이 있습니까?

모듈을 새 위치로 옮기고 레지스트리를 다시 빌드하기 만하면됩니다. 레지스트리가 다시 빌드되면 모듈 경로가 업데이트됩니다. 확인하십시오 registry_rebuild().

모듈에서 모든 코드를 다시 스캔하거나 디렉토리를 포함하여 데이터베이스에서 각 인터페이스 또는 클래스의 위치를 ​​저장합니다.

그러나 이것을 테스트하기 전에 데이터베이스를 백업하는 것이 좋습니다.

drush를 사용하는 경우 다음 명령을 사용하여 레지스트리를 다시 작성할 수도 있습니다.

drush cc registry

registry_rebuilddrush 명령을 설치할 수도 있습니다 .

// install registry_rebuild
drush dl registry_rebuild
// rebuild the registry
drush rr

로컬에서 프로덕션에서 백업을 복원하고 사물을 이동하고 관리 / 모듈을 누르거나 registry_rebuild ()를 실행하려고 시도했지만 치명적인 오류가 발생하는 것을 막지는 못했습니다. 일부 모듈은 자신의 hook_init ()에 include 또는 무엇이든 사용할 수 있거나 모듈에 의존하거나 Drupal이 부트 스트랩에서 찾을 수없는 메뉴 라우터 경로 세트를 가질 수 있기 때문에 나에게 의미가 있습니다. 궁극적으로 이것은 내가 한 일입니다 (경로가 다를 수 있음).

1 단계 : 사이트 / 모든 / 모듈을 사이트 / 모든 / 모듈 / 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');

2 단계 : 사용자 지정 네임 스페이스 모듈에 대해 사이트 / 모든 / 모듈 / 검색을 사이트 / 모든 / 모듈 / 사용자 정의로 교체

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_%';

3 단계 : dev 모듈을 sites / 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%';

4 단계 : 캐시가 지워 지므로 제대로 부트 스트랩됩니다.

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

참고 : 403 (액세스 거부)을 처리하기 위해 사용자 정의 모듈 또는 LoginToboggan과 같은 구성 요소를 사용하고이 프로세스 중에 로그 아웃 한 경우 포함 파일의 새 경로를 사용하도록 테이블 의 include_file열 을 업데이트해야 menu_roter합니다. . 아마도 드물게 발생합니다.

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

이러한 쿼리가 실행되면 (분당 초만 소요됨) admin / config / development / performance를 실행하고 메뉴 경로가 다시 작성되도록 캐시를 지우십시오.

Mark Sonnabaum : Drush Rebuild Project Paths 의 멋진 도구를 사용해보십시오 . 프로세스를 자동화합니다. 나를 위해 일했다. 물론 Drush를 사용합니다 .

그래도 사이트 데이터베이스 복사본에서 시도해 볼 것을 제안합니다.

기록을 위해 레지스트리를 다시 작성하는 훌륭한 drush 명령이 있습니다 : http://drupal.org/project/registry_rebuild

프로젝트 페이지에는 많은 정보가 있습니다.

첫째, 항상 데이터베이스를 백업하십시오. 따라서 간단한 작업으로 인해 문제가 발생하여 백업하지 않은 경우 스스로 쫓아 낼 수 있습니다.

모듈을 비활성화할지 여부는 중요하지 않습니다. 만일을 대비해서하고 싶을 수도 있습니다. 그런 다음이 작업을 수행하십시오.

1. (sitename) / admin / config / development / maintenance에서 사이트를 유지 보수 모드로 설정하십시오.
2. 파일 시스템에서 모듈을 실제로 이동하십시오.
3. (sitename) / admin / config / development / performance에서 캐시를 지우거나 모듈 페이지를 다시 저장하십시오.

다 했어요! Drupal은 설치된 모든 모듈을 다시 검색합니다.

Registry Rebuild 모듈 을 사용해보십시오 . 그것은 나를 위해 매번 작동했습니다.

다음은 모듈의 프로젝트 페이지에서 인용 한 것입니다.

Drupal 7에는 레지스트리가 절망적으로 빠져서 레지스트리 (PHP 클래스 및 파일과 함께 제공되는 파일 목록)를 다시 작성해야 할 때가 있습니다. 그러나 시스템이 부트 스트랩을 시도 할 때 일부 클래스가 필요하기 때문에이 정기적 인 캐시 지우기 활동을 수행 할 수없는 경우가 있습니다.

명령을 통해 Drush와 통합되는 Registry Rebuild 모듈을 사용할 수 있습니다 Drush RR.

기본적으로 다음 단계를 수행하십시오.

1. 모듈을 다른 디렉토리로 옮기고
2. 그런 다음 레지스트리 재 구축은 시스템 테이블을 재 구축하여 올바른 위치에 모듈을 가져옵니다.

먼저 DrupalEasy Podcast # 133을 통해이 모듈 / 드 러쉬 cmd를 사용하는 방법을 자세히 설명했습니다.

추신 : 물론, 먼저 사이트 백업을 수행하십시오 ...

/ admin / build / modules를 방문하면 시스템 테이블의 경로가 다시 작성됩니다. 때로는 drupal이 더 이상 부트 스트랩을 만들 수 없으므로이 경우이 솔루션이 작동하지 않습니다. 작동하지 않으면 이전 답변에서 설명한 것처럼 Drush Rebuild Project Paths 를 사용할 수 있습니다 . 부트 스트랩을 끊기 전에 새로운 drush 명령을 추가해야합니다. 새 명령을 추가하려면 readme 의 COMMANDS 섹션을 확인하십시오.

drush dl모듈 디렉토리 문제로 인해 작동하지 않는 데 문제가있었습니다 . 일반적으로 작업을 수행하기 위해 간단히 붙여 넣을 수있는 스택 답변을 좋아합니다. 여기에 적절한 사이트 디렉토리에있는 경우 Drush Rebuild Registry를 설치하고 사이트에서 실행하는 몇 줄이 있습니다.

pushd ~  # good if drush on your site is broken because of moved modules
drush dl -y registry_rebuild
popd 
drush rr

나는 진정한 drupal-esk 답변을 100 % 확신하지 못하지만 내 경험에 따르면 :

서버에 FTP로 연결할 때 실수로 내 사용자 정의 모듈 폴더 중 하나를 다른 사용자 정의 모듈 폴더로 옮겼습니다. 그들은 여전히 ​​일했다. Drupal은 다른 모듈의 폴더에있는 동안에도 별도의 모듈로 인식 한 것 같습니다. 모듈을 비활성화하지 않아도됩니다.

**이 모듈에는 .install 파일이 없으므로 중요한지 확실하지 않습니다.

Drupal 배포판은 이것을 잘 처리하지 못하기 때문에 최근 Panopoly 사이트 에서 Entity API 사본을 실수로 sites/all/끝내면 아무것도 작동하지 않습니다. 레지스트리 재 구축, 모듈 페이지 및 기타로드로 인해 치명적인 오류가 발생했습니다.

Panopoly의 많은 다른 모듈에 필요한 Entity API와 같은 것을 이동 해야하는 경우 모듈을 비활성화하는 것은 간단하지 않습니다.

이 문제를 해결하려면 Entity API의 경우 다음과 같이하십시오.

1. 시스템 테이블에서 경로를 업데이트하십시오.

   UPDATE `system` 
     SET `filename` = REPLACE(
       `filename`, 
       'sites/all/modules/entity', 
       'profiles/panopoly/modules/contrib/entity'
     );

2. 그런 다음 레지스트리를 다시 빌드하십시오.

   drush rr

드루팔 7

우선 시도하십시오 drush rr.

작동하지 않으면 파일을 이동 한 후 Drupal 루트 디렉토리에서 다음 Drush 명령을 시도하십시오.

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

위의 방법으로 문제가 해결되지 않으면 경로에 대한 기존 정보가있는 테이블을 찾으십시오.

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

아무것도 발견되지 않으면 외부 캐시임을 의미합니다.

그렇다면 다시 시작하는 것을 잊지 마십시오 (예 :

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

더보기 : Drupal에서 캐시를 지우는 데 어떤 방법이 사용됩니까?

또는 파일을 이동 한 후 다음 MySQL 쿼리를 시도 할 수 있습니다.

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");

contrib / dev / patched / custom 하위 폴더로 모듈을 옮기는 것이 좋습니다. 그러나 성능 향상은 없지만 실용적이고 미적인 이유로 수행됩니다. 이것은 미래 개발자의 삶을 더 쉽게 만들어 줄 것입니다.

라이브 사이트에서 문제없이 대부분의 contrib 모듈을 하위 폴더로 이동할 수 있습니다. 나중에 캐시를 비워야합니다. drush를 사용하지 않고 더 이상 캐시 지우기 페이지에 액세스 할 수없는 경우 /update.php를 방문하거나 캐시 테이블을 수동으로 잘라야합니다. 엔터티 API 모듈을 이동할 때 마지막 비트 만하면됩니다.

핵심 모듈을 이동하는 것은 기술적으로 가능하지만 권장하지 않으며이를 수행 할만한 이유가 없습니다.

업데이트 : 엔티티 API와 같은 모듈을 이동하려면 레지스트리를 다시 작성해야 할 수 있습니다. registry_rebuild 페이지를 확인 하십시오.

sites / all / contrib를 가리키는 sites / all / modules 디렉토리에 sym 링크를 추가 할 수 있습니다. 문제가 해결되는지 확실하지 않습니다. 설치 프로파일 또는 drush make 파일을 포함한 다른 솔루션도 있습니다. 나는 그들에 대한 세부 사항을 제공 할만 큼 충분하지 않지만 적어도 그것은 당신이 볼 수있는 방향입니다.