Переход на Drupal 8

[ivnish]

Обсуждение миграции, пожалуйста, делать тут, а не на друпал.ру

[ivnish]

Например, @orion76 писал:

Я правильно понимаю, производить миграцию планируется "штатными" плагинами (в т.ч. и source-плагинами) "мигрирующих" контриб-модулей и вспомогательных (migrate_*)?

А не проще, вместо адаптации drupal.ru для миграции, кастомизировать саму миграцию?

[ivnish]

А не проще, вместо адаптации drupal.ru для миграции, кастомизировать саму миграцию?

Дело не только в миграции, а в поддержке тоже. Сейчас очень много кастомного кода, который тяжело поддерживать. Особенно тяжело становится, когда из команды уходит человек, который этот код писал. А такое бывает, это ведь OpenSource. Поэтому задача в первую очередь избавиться по-максимуму от кастома и заменить этот код на контриб. Собственно предлагаю тебе присоединяться именно к этим задачам, они помечены лейблом "Drupal 8"

[orion76]

хм.. не совсем понял, почему это нельзя было обсудить на drupal.ru, ну да ладно..

предлагаю тебе присоединяться именно к этим задачам

Да я только ЗА..

Но не совсем понятно, почему нельзя сразу на drupal 8 реализовать кастомный функционал контриб-модулями, а потом просто перенести необходимые данные.

Я понимаю, что наверное есть ситуации, когда проще и оптимальнее избавиться от кастома еще на семерке.

Но в остальных случаях получается двойная работа:
1.Релизовать кастом-функционал контриб-модулями на семерке
2.Релизовать его -же на восьмерке

[ivnish]

хм.. не совсем понял, почему это нельзя было обсудить на drupal.ru, ну да ладно..

Потому что не всем пользователям интересна "внутренняя кухня" проекта.

Но не совсем понятно, почему нельзя сразу на drupal 8 реализовать кастомный функционал контриб-модулями, а потом просто перенести необходимые данные.

Потому что это не просто переход на друпал 8. Это еще и слияние с командой https://dru.io.

[avakorin]

есть ситуации, когда проще и оптимальнее избавиться от кастома еще на семерке.

Да, потому что апгрейд на D8 — дело не быстрое, а поддерживать drupal.ru нужно уже сейчас.

[orion76]

@avakorin Да, потому что апгрейд на D8 — дело не быстрое,

так как раз, если избавиться от "двойной работы", этот процесс значительно ускориться

@itcrowd72 Потому что не всем пользователям интересна "внутренняя кухня" проекта.

Данная фраза как бы подразумевает, что все-таки пользователи, которым интересна "внутренняя кухня" проекта - есть.-)
Да, наверное не стоит выносить подобную инфу на главную или в топ форумов, но где-то на drupal.ru она должна быть. Потому что на данный момент узнать про "внутреннюю кухню" потенциальному волонтеру можно узнать только случайно нарвавшись на ее упоминание в комментах форума.
Да и у тех, кто про нее знает она стоит не напервом месте в списке задач, т.к. своя рубашка,- всегда ближе к телу. Значит необходимо переодически о ней напоминать и подогревать интерес.
На этом весь интернет держиться.. кроме drupal.ru -))

@itcrowd72 Это еще и слияние с командой https://dru.io.

Кстати, есть одно интересное направление, возможно даже в перспективе - в глобальной архитектуре Интернета, или как минимум в болшой его части:
http://www.wikireality.ru/wiki/%D0%A1%D0%B0%D0%B9%D1%82-%D0%B0%D0%B3%D1%80%D0%B5%D0%B3%D0%B0%D1%82%D0%BE%D1%80

как минимум, в данном контексте, оно позволяет не объединять комманды (т.к. обычно бывает, чем больше народу, тем больше "дурдом"-))), а обединять результаты их деятельности при помощи какой-то стандартной, в рамках всего проекта, "технологии" (обмена данными между основным сайтом-агрегатором и отдельными от него сервисами и вэб-приложениями)

Открываются огромные перспективы в горизонтальном расширении drupal.ru с участием "автономных" комманд или отдельных разработчиков.

[alexsco74]

Когда то был человек на форуме который писал "зеленый друпал" в русле использования контрибных модулей must have, как показало время вопрос особенно болезненно встает при миграции с 6 -7 -8 -9.
Сделать миграцию средствами коре, все что не укладывается остальное делать настройками в D8 и забирать через сервисы разово.