CiviCRM projesi için geliştirici ve sürdürücüyüm. Drupal 8 versiyon CiviCRM yapmaya çalışıyoruz ve uzun bir yolumuz var. Proje için büyük bir engelleyici bulmaya çalışan kolektif klavyelerimize karşı başımızı atıyoruz.

CiviCRM bir süredir Symfony kullandı ve içerilen versiyon Drupal ile birlikte gelen versiyondan farklı.

CiviCRM'yi Drupal 8 ile kurabiliriz, ancak kurduktan sonra başka bir Drupal modülünü kuramayız.

Ben bir şekilde Symfony CiviCRM sürümünün Drupal sürümünden önce yüklediği bir duruma düştüğüne inanıyorum ve bu sorunlara neden oluyor.

Herkes Symfony Drupal ile birlikte gelen farklı bir sürümünü içeren bir Drupal 8 modülü biliyor mu?

Son zamanlarda Ludwig projesiyle karşılaştım. Bu modül, genişleyen bir sınıftaServiceProviderBase ad alanlarının kaydedilmesini sağlar .

CiviCRM modülünün Drupal 8 sürümünün bir CivicrmServiceProvidersınıfı tanımlayan bir CivicrmServiceProvider.php dosyası ve bunun register()çalışmasına izin vermek için bir kap ad alanı ekleyen bir yöntem içermesi mümkün müdür ?

Birçok CiviCRM dosyaları var useDrupal gibi, Symfony'de ile başlayan ifadeleri burada .

Aslında CiviCRM Core'u Drupal doc_root / libraries klasörüne koyduk ve kütüphaneler modülünü kullanıyoruz.

Bu, CiviCRM Drupal modül 8.x sürümü için bir repo . Birisi bunun için sihirli iksire sahipse, topluluğumuzda birçok mutlu insan olacağını söyleyebilirim. Bize nasıl yardım edeceğinizi biliyorsanız, lütfen yapın.

CiviCRM yüklenir ve CiviCRM sayfaları çalışır. İşe yaramayan şey, CiviCRM kurulduktan sonra, yönetici / modüller sayfası aracılığıyla başka modüller yükleyemiyoruz. Bildiğim kadarıyla kırılan tek şey bu. Ayrıca Drush ile modüller kurmak, CiviCRM kurulduktan sonra çalışır.

CiviCRM kurulduktan sonra başka bir modül takmaya çalışmak aşağıdaki hataya neden olur:

PHP Önemli hata: 206 numaralı satırda /var/www/html/civi-for-d8/core/lib/Drupal/Core/DependencyInjection \ Definition :: setFactory () yöntemine çağrı 206 satırında

Bu Drupal 8.3.5. Drupal 8 için CiviCRM'yi temiz bir Drupal 8.4-dev örneğine yüklemeye çalışmak aşağıdaki hataya neden olur:

Drupal \ Component \ Serialization \ Exception \ InvalidDataTypeException: Ayrılmış "@" göstergesi düz bir skaler başlatamıyor; skaleri 8. satırda ("argümanlar: [@string_translation, @ civicrm.page_state]" yakınında) alıntılamanız gerekir. Drupal \ Component \ Serialization \ YamlSymfony :: decode () (/var/www/html/drupal84/core/lib/Drupal/Component/Serialization/YamlSymfony.php satır 40).

Bu yüzden, eğer CiviCRM, besteci (yani composer require civicrm/civicrm-coreDrupal kökünde) aracılığıyla Drupal 8'e yüklenmişse ve CiviCRM'nin Symfony kullanımı Symfony 2.8 veya 3.x (yani kullanımdan kaldırılmış işlevsellik kullanmayan) ile uyumluysa, bu işe yarayabilir.

Bu, her şeye iki sahip olmak yerine Drupal'ın tedarikçi dizinine yüklenir ve CiviCRM'nin Drupal 8'deki Symfony sürümünü kullanacağı anlamına gelir. Ancak CiviCRM daha sonraki Symfony sürümleriyle uyumluysa (Drupal için daha eski bir sürüm olsa bile) 6 ve 7 ve diğer CMS'ler) iyi olmalıdır.

Bence?

GÜNCELLENDİ: Evet, işe yarıyor - denedim. :-) Başlangıçta CiviCRM sayı kuyruğuna ( CRM-17652 ) aşağıda yayınladım , ancak tamlık için burada yeniden gönderiyorum.

Büyük fikir:

Besteci birçok insan için oldukça yeni olduğu için, bazı üst düzey besteciden CiviCRM'de yapılabilecek tek yoldan adım adım ilerlemeye çalışacağım:

• Composer, uygulamaların ihtiyaç duyduğu kütüphaneleri gerektirmesine izin verir (ve elbette kütüphaneler başka kütüphaneler gerektirebilir).
• Kütüphaneler, başka hangi kütüphanelere ihtiyaç duyduğunu ve hangi sürümlerle uyumlu olduğunu söyleyen bir composer.json dosyasına sahiptir (ancak belirli bir tek sürüm değil - genellikle ^2.4.3en az 2.4.3 ve en fazla (ancak değil) dahil) 3.0.0)
• Uygulamalar, gerekli kütüphaneleri ve çeşitli sürümlerle uyumluluğu benzer şekilde açıklayan bir composer.json'a sahiptir, ancak aralık gerçekten güncellemeye yardımcı olmaktır. Bir uygulama aynı zamanda belirli bir sürümler dizisi olan bir composer.lock dosyasına sahip olacaktır.
• Kütüphaneler ayrıca kendi testleri veya dağıtımları için bir composer.lock'a sahip olabilir (sürüm bağımlılığını paketlenmiş bağımlılıklarla oluşturmak gibi), ancak bir uygulama verilen kütüphaneyi gerektirdiğinde bu dikkate alınmaz (bkz. Https://getcomposer.org/doc/02 -libraries.md # kilit dosyası )
• Bir uygulama yeni bir kitaplık gerektirmek istediğinde, besteci uygulamanın gerektirdiği her şey (zaten yüklü olan tüm kitaplıklar ve bağımlılıkları dahil) ve yeni kitaplık arasında sürüm uyumluluğunun kesişimini bulur ve muhtemelen her şeyi sıralamak için bazı güncellemeler yapar ( veya uyumlu bir sürüm karışımı bulamazsa hata veriyor)
• Bu durumda, CiviCRM bir kütüphane ve belirli bir Drupal 8 sitesi uygulama (Drupal çekirdeğinin kendisi bir kütüphane)
• CiviCRM ^2.5, composer.json içinde Symfony "gerektirir" diyebilir ki bu , 3.0.0 sürümüne (3.0.0 sürümüne kadar)
• Bir Drupal 8 sitesi CiviCRM kullanmak istediğinde, site yöneticisi composer require civicrm/civicrm-coreCiviCRM kütüphanesini ve tüm bağımlılıklarını talep etmek için kullanır . CiviCRM, Symfony 2.8 (Drupal 8.3.x'te kullanılan gibi) ile uyumluysa, Drupal'ın tek Symfony 2.8'i kullanarak her şey kurulacak ve iyi çalışacaktır. Tüm bağımlılıklar Drupal'ın satıcı dizininde bulunur.
• Bununla birlikte, CiviCRM, Symfony 2.5'i composer.lock içinde tutabilir, bu da testlerin bunu kullanacağı ve Drupal 6 & 7 ve diğer CMS'lerin tarball'larının Symfony 2.5'i paketleyeceği anlamına gelir.

Teklif:

1. CiviCRM'nin composer.json dosyasını güncelleyin, böylece Drupal 8 gibi besteci tabanlı CMS'ler tarafından kitaplık olarak kullanılabilir (ancak muhtemelen diğerleri gelecekte bu şekilde hareket edebilir - besteci oldukça popüler hale geliyor)
2. CiviCRM çekirdeğinin Symfony 2.8 ve 3.0 (sırasıyla Drupal 8.3.x ve 8.4.x tarafından kullanılır) ile uyumlu olduğundan emin olun, ancak test için composer.lock ve dağıtım için tarball'da "resmi olarak desteklenen" sürümü (şu anda Symfony 2.5) saklayın. Birden çok Symfony sürümü ile uyumlu olmak göründüğü kadar zor olmayabilir - hem Symfony 2.8 hem de 3.0 ile uyumlu bir dizi kitaplık var. Sadece kullanımdan kaldırılan yöntemlerden / sınıflardan / özelliklerden kaçınmak meselesi olabilir! Composer.json dosyasının bunu yansıtacak şekilde güncellenmesi gerekecektir
3. CiviCRM kütüphanesini kütüphaneler dizinine kopyalamak yerine Drupal 8'e kurmak için besteci kullanın. Bu, Drupal 8'de 3. taraf PHP kitaplıklarını kurmanın normal yolu haline geliyor (örneğin, Drupal Commerce tarafından yaygın olarak kullanılmaktadır)

Besteci tabanlı CMS'ler için bunun doğru yol olduğunu düşünüyorum. Bu sorun şu anda Symfony ve Drupal'ı etkilemekle birlikte, PHP topluluğu besteci aracılığıyla daha fazla 3. parti kitaplığı kullanmaya başladığından, bu durum diğer sürüm çakışmalarına sahip diğer CMS'leri çok iyi etkileyebilir.

Test etmek için bazı çalışma kodları:

Söz verdiğim gibi, aslında bunu sınırlı derecede çalışmak için aldım :-) Tamamen buna bir Drupal / Composer / Symfony perspektifinden geliyorum - Bir ton CiviCRM deneyimim yok, bu yüzden muhtemelen bazı işlemimi aşağıda daha iyi yapmanın yolları. Ben herhangi bir tavsiye edilir!

1. Drupal 8.3.5'i (veya Drupal 8.4.x'in en son geliştiricisini) indirin ve yükleyin.
2. Kabuktaki kök dizine gidin ve CiviCRM'yi besteci aracılığıyla yüklemek için şu komutları çalıştırın: https://gist.github.com/dsnopek/56311dbea347874e75180883efabb620
3. Apache kullanıyorsanız, vendor / .htacess dosyasını kaldırın. Bu, Drupal'ın CSS / JS gibi kaynakların yüklenmesini engelleyen bir güvenlik önlemidir. Bunun uygun bir çözüm bulmak için Drupal projesiyle biraz işbirliği yapması gerekecektir, çünkü bu dosyanın tamamen kaldırılması üretim konusunda kötü bir fikirdir. Bkz . Besteci kitaplıklarından CSS / JS varlıklarını engelleyen vendor / .htaccess .
4. / Modules dizinine gidin ve git clone https://github.com/dsnopek/civicrm-drupal.git --branch composer-library
5. "Genişlet" sayfasına gidin ( /admin/modules) ve CiviCRM modülünü kurun
6. Drush ( drush cr) ile drupal önbelleği temizle
7. Oturumu kapatın ve CRM-19878'e göre yeniden oturum açın
8. CiviCRM çalışıyor! :-)

Tüm bunlardan sonra, CiviCRM, Drupal'dan Symfony 2.8 ve Drupal'ın satıcı dizinindeki bağımlılıkları kullanıyor ve kendi satıcı dizininden hiçbir şey yüklemiyor. Huzzah!

Bu değişikliklerden önce başarısız olan "Telefon" modülünü etkinleştirmeyi test ettim ( çoğaltma adımlarıma bakın ), ancak onlarla iyi çalışıyor. :-)

Bunun mümkün olduğunu düşünmüyorum.

Drupal 8.4 aslında aynı problemi olan drush ile ilgili benzer tartışmalar olmasına rağmen Symfony 3'e zaten geçti. bkz Drush 8.x Drupal 8.4.x yüklenmez ve Drush ustası Drupal 8.3.x yüklenmez ve Symfony'nin bileşenleri 3.2.6 için güncellenir

İki farklı symfony sürümü yüklemek mümkün değildir, ya entegrasyonunuzu bozarsınız ya da Drupal'ı bozarsınız. Belki symfony3 henüz 8.4'te olmayacak, ancak symfony2 için güvenlik desteği Drupal8 güvenlik desteğinden önce sona erecek, bu yüzden bir noktada geçiş yapmamız gerekecek.

Teorik olarak buradaki tek sorun dosya konumu ve sınıf ad alanıdır. Ne yazık ki besteci için bildiğim tek araç VERSION başına, sadece paket adı başına belirtmenize izin vermiyor.

Tamamen ayrı bir otomatik yükleyici olarak ayarlamayı denediniz mi?