Импорт сайтов из разных CMS на Drupal

[@seewald]

как насчет переноса пользователей?

[@ozware]

думаю, что нужно аналогично заполнить структуру stdClass минимальным набором полей и вызвать user_save

в этом плане очень сильно помогает модуль Devel, который показывает данные текущей ноды, т.е. те данные, которые надо заполнять.

вообще, толком нигде не написано про импорт, приходится по большей части методом научного тыка все делать))

[@taldy]

К сожалению похоже но не так же, в этом плане модуль user всегда отставал от node.

Там нужно передавать вторым параметром массив в котором ключи совпадают с именами колонок в таблице пользователей.

$new_account = array(
  'name' => $name,
  'pass' => $pass,
  'status' => 1,
  'roles' => array('subscriber'),
  'data' => serialize(array('portal_user_data' => array(...)),
);

$account = user_save(FALSE, $new_account);

Способ прямо-таки дореволюционный, но даже в 6-ке приходиться делать так. В 7-ке еще не смотрел, не знаю.

Это создание самого пользователя. А профайл пользователя — тот же нод, так что можно импортировать так же как написано в топике.

[@Dzen_Marketing]

Поля профиля можно передавать в этом же массиве, формат типа 'profile_fieldname', могу попозже исходники свои поднять

[@taldy]

Если так, то классно. В моем случае профайла не было, вот я и не стал копать глубже. Хотя формат и способ работы у user_save, согласитеть, отщепенческий.

[@LavrenovNN]

А я ухожу от Друпал! Написал на 6-ке модуль спортивной статистики (icehockey.su), задумал перенести на 7-ку — и проделав пол работы, бросил это дело. Почему? Да потому, что работа с Друпал сама по себе тяжёлая, медленная — и я просто устал от этого тормоза!

[@rbogdan]

Что бы ускорить эту работу нужно как можно больше использовать API Drupal'a. А в некоторых случаях, можно ещё и API сторонних модулей. Но для этого нужно потратить ни один месяц, что бы изучить всё это.

Вот и автор в статье показал, как ускорить и упростить перевод контента сайтов на друпал с помощью его API.

[@LavrenovNN]

А что толку что-то использовать. Сама работа с Друпал, а именно с админкой — это просто гемморой

[@Dzen_Marketing]

Напишите в «Я негодую», данный топик не самое лучше место для рассказа на тему «Я ниасилил Друпал»

[@pvasili]

LavrenovNN геморой у того, кто не умеет и не знает как «это» делать правильно.
Кривая обучения в Drupal довольно кривая, невозможно хорошо понять и изучить идеологию и устройство стистемы, тем более изучить хотя бы поверхностно >7000 модулей за 1-2 месяца. Отсюда и стоны новичкой… Нописание своего велика, зачастую им проще, чем понять как делать правильно :)

Топик стартеру: вы не начать изучение вопроса с проекта migrate?

[@ozware]

Проект migrate я не смотрел. Имхо, более быстро написать свой скрипт импорта, который использует API, чем разбираться со сторонним модулем. Тем более, что наверняка у того модуля есть какие-то ограничения, т.к. всего не предусмотришь.

Мое решение более гибкое, хотя и низкоуровневое.

[@negodnik]

Поздравляю, вы придумали решение — читать документацию. Оно действительно очень гибкое и низком уровне

[@LavrenovNN]

Я два года имел дело с Друпал, и знаю его от и до… тем более, имеется опыт написания модуля под него. И что тут правильно делать? О чём вы говорите? Если я работаю в бэкенде, и жду выполнения операций по 10-20 секунд — это нормально? Вот и говорю, я о том, что с Друпалом работать очень сложно из-за его тормозов. Если бы не было с чем сравнить — то и не заикнулся бы. Моё мнение в том, что Друпал стал слишком толстый и неповоротливый, и 7 стала ею ещё больше.

[@nuclear]

А на что перешли то?

[@Washington]

Я 5-ый год ковыряю друпал и до сих пор знаю его не очень хорошо

[@Washington]

Не туда ответил, извиняюсь. Ответ был ЛавреновННу.

[@LavrenovNN]

Я не для того подметил, что считаю себя истинным гуру — а в том плане, что не являюсь новичком. Да и что там собственно знать? Стоит пару модулей и тем сделать и всё становится очень понятно, а в чём это отображается — так это система хуков, работа с базой данных, построение форм, взаимодействие с другими модулями, ну и ещё несколько моментов. ВСЁ!!! И можно делать что пожелаешь… а отказ от Друпала обусловлен именно скоростью работы админки, а не фронтенда — где всё что можно, можно закэшировать.

[@Dzen_Marketing]

Проведём эксперимент?

[@LavrenovNN]

pimcore

[@ozware]

Очень странно…

Ну а профайлинг mysql пробовали делать? Может надо где-то индексы добавить?

Или если очень много кода обрабатывается (это ж сколько тогда должно быть кода?), то пробовали ли использовать кеширование?

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

[@Dzen_Marketing]

Хостинг сменить не пробовали?

[@LavrenovNN]

Что делать правильно? Работать с админкой? Причём тут кривая? Если на обновление контента состоящей из 10 страниц, у меня уходит пол часа — это нормально? Только не советуйте мне купить новое железо! Не надо… у меня всё в порядке! Другие системы просто летают (modx, joomla1.6, pimcore, typo3 и ...)

[@Washington]

Полчаса — это что-то невероятное. Мы каких то подробностей не знаем?

[@ozware]

Да, к сожалению, у друпала есть один существенный недостаток — это высокий порог входа. Требуется много времени, чтобы изучить его.

Насчет тормоза не согласен, есть много кеширующих модулей. Мои сайты на друпал просто летают. Нужно только настроить кеширование.

[@Washington]

Я думаю у Forbes нагрузка очень немаленькая, тем не менее он прекрасно на друпале пашет.

[@Dzen_Marketing]

Forbes
Sportbox
Это из «Толстых», там соответствующий штат
Из поменьше и простых:
citaty.info
hr-portal.ru
fermer.ru (сезонный спад)
да даже тот же htmlbook.ru, около 70 000 просмотров, но имеет, вполне неплохо и расположен на виртуальном хостинге, кстати

[@Washington]

У нас Казкоммерцбанк один из сайтов на друпале держит, насколько знаю сайт Федекса на друпале, еще че-то было.

[@Washington]

Ну сайтик Аврил Лавин тоже на нем, да.

[@Dzen_Marketing]

Я специально указал русско-язычные сайты.
Во-первых я знаю их инфраструктуру, во-вторых чтобы не говорили потом другие «А на Западе у половины сайтов свой ДЦ»

[@Washington]

А, ну логично.

[@sky_lord]

Кстати, они в том году рассказывали на конференции, как его делали. Ничего сверхестественного — Boost поставили и все. Единственное, говорят, нужно было заморочиться с выводом пары динамических блоков и какая-то js-ная карусель изначально с Бустом глючила — надо было ее допилить децл. А в остальном — все стандартно и скучно — cck, views и готовые модули…

[@vooD]

Еще есть Node Import. Это для совсем ленивых.

[@negodnik]

Не. Шаг влево — шаг вправо, и модуль разводит руками и хлопает глазками, не находя себе оправдания. Только API. А с 7-ки — так совсем просто.

[@slavik]

ImageCache, возможно, не генерирует файлы из-за того, что у многих хостеров картинки обрабатываются сразу nginx-ом (404 не доходит до бекенда), сам с этим провозился в свое время на шареде (уже думал и картинки делать вида file.jpg.htm, чтобы до бекенда доходило), решил — костылями в шаблоне ноды (вызывать файл прямым запросом к ядру — site.com/?q=path/imagecache/file.jpg, заполнять например alt, а для картинки с заполненным альтом — выводить прямой путь), тогда картинка сохраняется и все работает

[@ozware]

Я всяко пробовал: и на шареде, и на собственном сервере и nginx и локально на денвере — везде глючит. Проще принудительно генерить изображения, чем ждать когда ImageCache сообразит.

[@stalkers]

sysoev.ru/nginx/docs/faq.html — читать в самом низу

Вообще, довольно распространенная трабла — imagecache слабо дружит с nginx'ом без особого шаманства. Суть траблы заключается в том, nginx некорректно работает с путями, и при попытке аплоада просто не видит куда складывать файлы, а потому отправляет в /dev/null

[@andyceo]

а еще начиная с шестого друпала есть batch operations, которые позволяют не вылезти за пределы time limit PHP. затравка: api.drupal.org/api/drupal/includes--form.inc/group/batch/6

господа, в друпале все есть. Читайте книжки и доки.

[@Dzen_Marketing]

Так же добавлю про очереди введённые в Drupal 7 и бекпортированные на Drupal 6

[@IRuslan]

Для больших и сложных переездов рекомендую модуль Migrate.
Мощная штука.
Есть интеграция с drush, т.е. проблем с объемами и тайм лимитами не будет.
Можно полностью откатить «чужеродный» контент в любой момент, и накатить по заново.

[@ozware]

Уже второй человек мне рекомендует этот модуль, придется его посмотреть)))

[@pvasili]

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

Посмотрите отдельно node_import, user_import. Для 7 интересный модуль datasources.
Для большинста популярных систем есть готовые решения, такие как: wp2drupal, phpnuke2drupal, phpbb2drupal, joomla2drupal, spip2drupal, vbtodrupal…

Просматривайте иногда список по тегу drupaler.ru/tag/module/function/migratsiya

[@stalkers]

Для действительно больших и сложных переездов всё-таки приходится писать руками, увы. Впрочем, зависит от ситуации.

[@Krymsky]

еще советую взглянуть на модуль Feeds

[@danSamara]

Совершенно непонятно какое отношение имеет заголовок к содержимому.

Что я вижу в статье? Три литра воды и пример использования node_save. Ещё генерация картинок, которая глючит только у автора.

Если так хочется изобрести свой велосипед для импорта контента из других БД, то, как минимум, надо описать: node_save, user_save, taxonomy_term_save, drupal_write_record и, самое главное!, детально разобрать Batch API! Иначе при импорте нескольких десятков тысяч материалов или пользователей, ваш скрипт загнётся на первых сотнях, если не поменять лимиты PHP на исполнение (а на шаред хостингах это не всегда разрешено).

Если же велосипед изобретать неохота, тогда надо сделать обзор модулей импорта, в том числе migrate. Аргумент «я его не осилил» не должен присутствовать в статье с таким заголовком.

[@Pagefest]

Статья практически ни о чём… Всё что осталось послевкусием от прочтения «что-то можно как-то переносить в Drupal».

[@negodnik]

Просто кто-то узнал, что ноды можно создавать не только через модули импорта ;)

[@Nikiit]

заголовок просто неправильный, скорее всего «Импорт данных в CMS Drupal».

[@scoff]

Делал и так, затем стал использовать модуль migrate (в D6 и D7). «Ваш» (обычный то есть) способ хорошо подходит для небольшого беспроблемного переноса, когда всё делается за 1 проход и один раз. Migrate же позволяет «обкатать» схему миграции, попробовать, откатиться назад и что-либо доделать (он хранит карту связей новое-старое).