it-swarm.asia

كيفية نقل الوحدات المثبتة من / sites / all / modules / * إلى / sites / all / contrib / modules / *

لقد كنت أبحث عن إجابات لهذا السؤال دون أي حظ على الإطلاق. من ما ألاحظه في بنية قاعدة البيانات ، يتم تحديد الموقع إلى الوحدات في جدول "النظام". الحل الوحيد لدي هو كتابة استعلام SQL لتحديث عمود "اسم الملف".

هل هناك حل أفضل/أنظف في حل هذا ، على سبيل المثال ، وحدة مساهمة؟

34
Logi

ما عليك سوى نقل الوحدات النمطية الخاصة بك إلى موقعك الجديد وإعادة بناء السجل. عندما يعيد التسجيل تحديث المسار إلى الوحدات النمطية. تحقق registry_rebuild() .

تفحص جميع التعليمات البرمجية في وحدات أو تتضمن أدلة ، وتخزين موقع كل واجهة أو فئة في قاعدة البيانات.

على الرغم من أنني أوصيك بعمل نسخة احتياطية من قاعدة بياناتك قبل اختبار ذلك.

إذا كنت تستخدم drush ، يمكنك أيضًا إعادة بناء السجل باستخدام الأمر التالي:

drush cc registry

يمكنك أيضا تثبيت registry_rebuild أمر الطير:

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

لقد استعدت نسخة احتياطية من الإنتاج محليًا وحاولت فقط نقل الأشياء وضرب المشرف/الوحدات النمطية أو تشغيل Registry_rebuild () ولكنها لم توقف حدوث أخطاء فادحة. هذا منطقي بالنسبة لي نظرًا لأن بعض الوحدات قد تستخدم تضمين أو أي شيء في hook_init () الخاصة بها ، أو قد يكون لديك مسار مسار قائمة توجيه يعتمد على وحدة أو يتضمن ذلك Drupal لا يمكن العثور عليه على bootstrap. في النهاية ، هذا ما فعلته (قد تكون مساراتك مختلفة):

الخطوة 1: استبدال المواقع/الكل/الوحدات النمطية بالمواقع/الكل/الوحدات النمطية/المساهمة

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: نقل وحدات ديف إلى المواقع/جميع/وحدات/ديف

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: امسح ذاكرة التخزين المؤقت بحيث تكون الأشياء bootstrap بشكل صحيح

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

ملاحظة: إذا كنت تستخدم وحدة مخصصة أو مساهمة مثل LoginToboggan للتعامل مع 403 (تم رفض الوصول) وقمت بتسجيل الخروج أثناء هذه العملية ، فقد تحتاج إلى تحديث 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 وقم بمسح ذاكرة التخزين المؤقت بحيث يتم إعادة إنشاء مسارات القائمة.

10
Charlie Schliesser

جرب الأداة الرائعة من Mark Sonnabaum: Drush Rebuild Project Paths . أتمتة العملية ؛ عملت بشكل رائع بالنسبة لي. يستخدم Drush ، بالطبع.

سأؤيد الاقتراح بأن تجرب هذا على نسخة من قاعدة بيانات موقعك.

9
greg_1_anderson

للتسجيل ، هناك أمر كبير لإعادة بناء السجل: http://drupal.org/project/registry_rebuild

هناك الكثير من المعلومات في صفحة المشروع.

7
jonhattan

أولاً ، دائمًا نسخ قاعدة البيانات احتياطيًا ، من السهل جدًا القيام بذلك ستركل نفسك إذا حدث خطأ ما ولم تقم بعمل نسخة احتياطية.

لست متأكدًا مما إذا كان الأمر مهمًا إذا قمت بتعطيل الوحدات أم لا ؛ قد ترغب في القيام بذلك ، فقط في حالة. ثم قم بما يلي:

  1. ضع موقعك في وضع الصيانة على (sitename)/admin/config/development/maintenance
  2. قم بتحريك الوحدات النمطية الخاصة بك في نظام الملفات.
  3. امسح ذاكراتك المؤقتة في (sitename)/admin/config/development/performance ، أو أعد حفظ صفحة الوحدات النمطية الخاصة بك.

كله تمام! Drupal سيعيد البحث عن جميع الوحدات المثبتة.

5
John Laine

لماذا لا تجرب وحدة Registry Rebuild . عملت في كل مرة بالنسبة لي.

هنا اقتباس عنها (من صفحة مشروع الوحدة):

هناك أوقات في Drupal 7 عندما يحصل التسجيل على خرطوم ميؤوس منه وتحتاج إلى إعادة بناء السجل (قائمة PHP والملفات التي يستخدمونها) في بعض الأحيان ، مع ذلك ، لا يمكنك القيام بهذا النشاط العادي لمسح ذاكرة التخزين المؤقت لأن بعض الصفوف مطلوبة عندما يحاول النظام التمهيد.

4
drupalastic

يمكنك استخدام Registry Rebuild ، والتي تتكامل مع Drush عبر Drush RR أمر.

في الأساس ما تفعله هذه الخطوات:

  1. نقل الوحدات النمطية الخاصة بك إلى دليل آخر ، و
  2. سيقوم برنامج Rebuild بإعادة إنشاء جدول النظام للحصول على الوحدات النمطية في المكان الصحيح.

لقد تعلمت/اكتشفته لأول مرة عبر DrupalEasy Podcast # 1 ، والذي يشرح أيضًا كيفية استخدام هذه الوحدة/drm cmd.

ملاحظة: بالطبع ، قم أولاً بعمل نسخة احتياطية من موقعك ...

3
Pierre.Vriens

واجهت بعض المشاكل مع 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
2
kqw

لست متأكدًا بنسبة 100٪ من إجابة دروبال إسك الحقيقية ولكن في تجربتي:

نقلت عن طريق الخطأ أحد مجلدات الوحدة النمطية المخصصة الخاصة بي إلى مجلد وحدة نمطية مخصص آخر عند FTPing إلى الخادم. كلاهما لا يزال يعمل. Drupal قد أدركها كوحدة منفصلة حتى أثناء وجودها في مجلد وحدة أخرى ، ولم يكن علي تعطيل الوحدة.

** لا تحتوي هذه الوحدة النمطية التي قمت بنقلها على ملف .install لذا لست متأكدًا مما إذا كان ذلك مهمًا.

2
Exziled

قم بزيارة/admin/build/modules سيعيد بناء المسارات في جدول النظام. في بعض الأحيان drupal لا يمكن bootstrap لم يعد هذا الحل يعمل في هذه الحالة. إذا لم يفلح يمكنك استخدام Drush Rebuild Project Paths كما ذكر في إجابة سابقة. يجب عليك إضافة الأمر drush الجديد قبل كسر bootstrap بالرغم من ذلك. لإضافة الأمر الجديد ، تحقق من readme ' قسم الأوامر

2
Zatox

يوصى بنقل الوحدات النمطية الخاصة بك إلى مجلدات فرعية تساهم/dev/patched/مخصصة. لا توجد مكاسب في الأداء ومع ذلك ، يتم ذلك لأسباب عملية وجمالية. هذا سيجعل حياة المطورين المستقبليين أسهل.

يمكنك نقل معظم وحدات المساهمة إلى مجلدات فرعية بدون مشكلة على موقع مباشر. يجب عليك مسح ذاكرة التخزين المؤقت بعد ذلك. إذا كنت لا تستخدم drush ووجدت أنه لا يمكنك الوصول إلى صفحة مسح ذاكرة التخزين المؤقت بعد الآن ، فسيتعين عليك زيارة /update.php أو اقتطاع جداول ذاكرة التخزين المؤقت يدويًا. لم يكن لدي سوى القيام بالجزء الأخير عند نقل وحدة واجهة برمجة تطبيقات الكيان.

نقل الوحدات الأساسية ممكن تقنيًا ، لكنني لا أوصي به ولا أرى أي سبب وجيه للقيام بذلك.

تحديث: قد يتطلب نقل الوحدات النمطية مثل واجهة برمجة تطبيقات الكيان إعادة إنشاء السجل. تحقق من Registry_rebuild الصفحة.

1
gbyte.co

توزيعات دروبال لا تتعامل مع هذا بشكل جيد ، لذلك في الآونة الأخيرة بعد انتهاء عرضي بنسخة من Entity API in sites/all/ على موقع Panopoly ، لم ينجح أي من هذا. إعادة بناء التسجيل ، وتحميل صفحة الوحدات النمطية وكل شيء آخر تسبب في خطأ فادح.

لا يعد تعطيل الوحدة أمرًا بسيطًا سواء إذا كان عليك نقل شيء مثل Entity API الذي تطلبه أطنان من الوحدات الأخرى في Panopoly.

لحل هذه المشكلة ، بالنسبة إلى Entity API ، ستفعل شيئًا كهذا:

  1. تحديث المسار في جدول النظام:

    UPDATE `system` 
      SET `filename` = REPLACE(
        `filename`, 
        'sites/all/modules/entity', 
        'profiles/panopoly/modules/contrib/entity'
      );
    
  2. ثم قم بإعادة إنشاء التسجيل:

    drush rr
    
1
ergophobe

دروبال 7

بادئ ذي بدء حاول drush rr .

إذا لم تنجح ، بعد نقل الملفات ، جرب أوامر Drush التالية في Drupal dir root:

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

مشاهدة المزيد: ما هي الطريقة المستخدمة لمسح ذاكرة التخزين المؤقت في دروبال؟


بدلاً من ذلك ، يمكنك تجربة استعلامات 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");
1
kenorb