Можно ли написать сценарий для ввода данных с помощью Drupal?

Существует пара модулей Drupal, посвященных различным сценариям внешнего (массового) импорта - проверьте этот обзор для вариантов / сравнений.

Если у вас есть очень специфические потребности, вы можете написать свой собственный модуль, используя существующие и ссылки / подсказки, предоставленные googletorps (+1) для руководства, как выполнить фактическую вставку, игнорируя обобщения.

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

В любом случае, то, что вам нужно для этого, очень похоже на то, что Mac отвечает здесь:

В этом случае вам не нужен весь специальный материал file_field, но вам все равно нужно вставить значения для различных полей cck, которые могут быть у вас, а также тела и заголовка узла. После установки значения, которое вы можете получить непосредственно из своей базы данных, вы можете сохранить свой узел.

Если вы подключаетесь к базе данных напрямую, вам необходимо иметь тот же тип, что и тот, который вы используете для drupal, или делать это вне Drupal api. Если вы действительно используете для этого drupal API, взгляните на db_set_active ()

Хенрик и Googletorp уже сделали много хороших предложений.

Несколько дополнительных элементов, которые следует учитывать при разработке своей стратегии:

1. Собираетесь ли вы создать полноценный электронный магазин (предположительно реализованный с помощью ubercart) или просто настройка просмотра узлов, просто чтобы представить инвентарь посетителям сайта?
2. Сколько товаров вы собираетесь импортировать?
3. Как часто вы собираетесь их повторно импортировать?

Решения, которые я бы обязательно исключил:

• POST: как прокомментировал googletorp, это было бы слишком сложно.
• Внешний скрипт. Данные разбросаны по нескольким таблицам, и при вставке узла срабатывает множество ловушек. Единственное исключение - если вы выполните сценарий PHP, который сначала выполняет загрузку (см. Структуру index.php или xmlrpc.php, чтобы увидеть, как это работает), но в этом случае я бы предпочел вообще модуль: гораздо более элегантный, портативный, легко обслуживаемый.

Решения, которые я бы поддержал:

• Создайте свой собственный модуль! Как указано в googletorp, я привел пример кода о том, как добавить поля CCK в этот ответ.
• Да, это ... единственное, во что я верю! ;)

Однако не менее важно то, что я узнал, - это выбор подходящего источника данных для импорта. Вот мое мнение:

• Чтение непосредственно из БД: подходит только в том случае, если вам нужно импортировать данные раз и навсегда и, если схема БД экспортирующего приложения достаточно проста для построения разумных запросов. Программное обеспечение меняется и развивается, а за ним следуют схемы БД. Если вы обнаружите, что через два месяца вам потребуется повторный импорт, а схема вашего другого приложения изменилась, вам придется изменить свой код, изменить тесты и т. Д. И т. Д.
• Используйте файлы XML: если ваше исходное приложение может экспортировать в этом формате, с PHP 'SimpleXML и Xpath + типизация PHP, это действительно легкий ветерок получить данные в желаемом формате за считанные минуты. Единственным недостатком этого метода является то, что он полагается на ... файлы. Итак, если вам нужен периодический беспилотный и автоматический импорт, немного затруднительно предвидеть все проблемы, которые могут произойти (неправильные разрешения для файловых систем, поврежденные файлы, неправильная кодировка ...) и принять контрмеры. . И наоборот, мне очень нравится этот метод, потому что я знаю, что кто-то будет постоянно контролировать процесс импорта и может вмешаться в случае проблем.
• Веб-сервис: это то, что мне нравится больше всего, если мне приходится импортировать автоматически и периодически. Самым большим преимуществом является то, что два приложения «разговаривают» друг с другом и раскрывают часть своей бизнес-логики, так что вы можете провести сеанс, который выглядит следующим образом: «Эй, мне нужны все продукты, цены на которые изменились с прошлой недели. "-" вот ты где, их должно быть 127, в трех категориях, ты это копируешь? " - «Ах да ... Получил все четко и ясно: 127 пунктов и 3 категории!». Это упрощает много перехвата ошибок и исключений. В то время как Drupal работает как потребитель и поставщик веб-сервисов, вам придется реализовать веб-сервис также в другом приложении, и это может быть, а может и нет: это полностью зависит от экспортирующего приложения.

HTH!

CCK или иначе, это просто хорошо сформированный запрос POST (предположительно), так что конечно, дерзайте.

Если ваши исходные данные находятся в MySQL, я бы посмотрел на модуль Migrate для создания контента. Вот отрывок со страницы проекта:

... предоставляет гибкую структуру для переноса контента в Drupal из других источников (например, при преобразовании веб-сайта с другой CMS в Drupal). По умолчанию включена поддержка создания основных объектов Drupal, таких как узлы, пользователи, файлы, термины и комментарии - ее можно легко расширить для миграции других типов контента. Контент импортируется и откатывается с помощью встроенного веб-интерфейса (модуль Migrate UI) или включенных команд Drush (настоятельно рекомендуется).