当前位置：文江博客话题详情

是否可以使用 Drupal 编写数据输入脚本？

发布于 2024-08-12 06:07:27 字数 93 浏览 4 评论 0 原文

我正计划将商店的库存放在 Drupal 站点上，我想知道是否可以创建一个脚本（也许在 python/php 中？）来使用 CCK 自动将数据输入到 Drupal？提前致谢！

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

寒冷纷飞旳雪 2024-08-19 06:07:27

有几个 Drupal 模块专门用于不同的外部（批量）导入场景 - 请查看此概述进行选项/比较。

如果您有非常具体的需求，您可以使用现有模块和 googletorps 提供的链接/提示 (+1)，指导如何在忽略概括的情况下进行实际插入。

回复收藏 0 原文

熟人话多 2024-08-19 06:07:27

最快、最简单的事情是使用您为该案例制作的一个小 Drupal 模块来完成这些工作，而不必向服务器发送大量帖子并在节点负载上花费资源等等。

无论如何，你所需要的与 mac 的答案非常相似此处：

在这种情况下，您不需要所有特殊的 file_field 内容，但您仍然需要插入可能拥有的不同 cck 字段的值以及节点正文和标题。设置可以直接从数据库获取的值后，您可以保存节点。

如果直接连接到数据库，则需要具有与用于 drupal 的类型相同的类型，或者在 Drupal api 之外进行操作。如果您确实使用了 drupal API，请查看 db_set_active()

回复收藏 0 原文

机场等船 2024-08-19 06:07:27

Henrik 和 Googletorp 已经提出了很多好的建议。

设计策略时需要考虑的一些其他因素：

您是否打算建立一家成熟的电子商店（大概是通过 ubercart）或者您只是设置节点视图，只是为了向站点访问者展示库存？
您要进口多少产品？
您打算多久重新导入一次它们？

我肯定要排除的解决方案：

POST： 正如 googletorp 所评论的，它会过于复杂。
外部脚本：你无法真正避免使用drupal API（除非你喜欢危险地生活和/或有时间浪费），无论它们是核心API还是Ubercart的API。数据分散在多个表中，插入节点时会触发大量钩子。唯一的例外是，如果您要执行一个首先执行引导程序的 PHP 脚本（请参阅 index.php 或 xmlrpc.php 的结构以了解其工作原理），但是在这种情况下，我宁愿选择一个模块：更优雅、更便携、更易于维护。

我支持的解决方案：

做你自己的模块！ 正如 googletorp 所指出的，我提供了一些关于如何在这个答案。
是的，那就是……我唯一相信的！ ;)

然而，我学到的同样重要的是选择合适的导入数据源。这是我的观点：

直接从数据库读取：只有当您必须一劳永逸地导入内容时才好并且如果导出应用程序的数据库模式足够简单以构建合理的查询。软件发生变化和发展，数据库模式也随之变化和发展。如果您发现自己需要在两个月内重新导入，并且其他应用程序的架构已更改，则您将不得不更改代码、更改测试等等...
使用 XML 文件：< /strong> 如果您的原始应用程序可以以这种格式导出，则使用 PHP 的 SimpleXML 和 Xpath + PHP 类型转换，以您想要的格式获取所需的数据确实是一件轻而易举的事情。想要在几分钟之内。此方法的唯一缺点是依赖...文件。因此，如果您需要定期进行无人值守和自动导入，那么预见所有可能发生的问题（文件系统的错误权限、损坏的文件、错误的编码......）并采取对策是一件很痛苦的事情。反之亦然，我非常喜欢这种方法，因为我知道有人会一直监督导入过程并且可以在出现问题时进行干预。
Webservice： 如果我必须以自动且定期的方式导入，那么这是我最喜欢的服务。最大的优点是这两个应用程序可以相互“对话”，并公开它们的一些业务逻辑，这样您实际上就可以进行一个如下所示的会话：“嘿，我需要自上周以来价格已更改的所有产品” - “给你，应该是 127 个，分三类，你明白了吗？ - “哦，是的...全部清晰响亮：127 个项目和 3 个类别！”。这大大简化了错误和异常的捕获。虽然 Drupal 可以作为 Web 服务使用者和提供者，但您还必须在其他应用程序上实现 Web 服务，这可能很困难，也可能并不困难：它完全取决于导出应用程序。

哈！

Lots of good suggestions have been done by Henrik and Googletorp already.

A few additional elements to consider to design your strategy:

Are you going to do a full-fledged e-store (presumably realised with ubercart) or are you simply setting up a view of nodes, just to present the inventory to site visitors?
How many products are you going to import?
How often are you going to reimport them?

Solutions that I would feel to exclude for sure:

POST: as commented by googletorp, it would be overly complicated.
External script: you can't really avoid (unless you like to live dangerously and/or have time to waste) using drupal API, whether they are the core ones or those of ubercart. Data is scattered across several tables, and there are plenty of hooks that are triggered when a node is inserted. The only exception is if you would do a PHP script that perform the bootstrap first (see the structure of index.php or xmlrpc.php to see how it works), but in that case I would rather go for a module altogether: much more elegant, portable, maintainable.

Solutions that I would support:

Do your own module! As pointed out by googletorp, I gave some sample code on how to add CCK fields in this answer.
Yes, that is... is the only one I believe in! ;)

However what I learned is equally important, is to pick a suitable source of data for the import. Here's my opinion:

Read directly from DB: Good only if you have to import stuff once and for all and if the DB schema of the exporting application is simple enough to build sensible queries. Software changes and evolves, and DB schemas follow. If you find yourself in the need of re-importing in two months time and the schema of your other application has changed, you will have to change your code, change tests, etc, etc...
Use XML files: If your original application can export in this format, with PHP' SimpleXML and Xpath + PHP typecasting it's really a breeze to get the data you want in the format you want in a matter of minutes. The only downside of this method is that relies on... files. So, if you need to have periodic unmanned and automatic imports, it's a bit of a pain to foresee all the problems that can happen (wrong permissions on filesystems, corrupted files, wrong encoding...) and to put in place counter-measures. Vice-versa, I like this method a lot for when I know somebody will be supervising the import process all the time and can intervene in case of troubles.
Webservice: That is the one I like the most if I have to import in an automatic and periodic fashion. The biggest advantage is that the two applications "talk" to each other, and expose some of their business logic, so that you can actually have a session that looks like: "hey, I need all the products that have changed prices since last week" - "here you are, they should be 127, in three categories, do you copy that?" - "Oh yeah... Got all of them loud and clear: 127 items and 3 categories!". This simplify a lot trapping errors and exceptions. While Drupal works out the box as a webservice consumer and provider, you will have to implement webservice also on the other application, and this might or might not be difficult: it totally depends from the exporting application.

HTH!

回复收藏 0 原文

云仙小弟 2024-08-19 06:07:27

CCK 或其他方式，这只是一个格式良好的 POST 查询（大概），所以当然，继续吧。

回复收藏 0 原文

婴鹅 2024-08-19 06:07:27

如果您的源数据位于 MySQL 中，我将查看 Migrate 模块来创建内容。以下是其项目页面的摘录：

...提供了一个灵活的框架，用于将内容从其他来源迁移到 Drupal（例如，将网站从另一个 CMS 转换到 Drupal 时）。开箱即用，支持创建核心 Drupal 对象，例如节点、用户、文件、术语和注释 - 它可以轻松扩展以迁移其他类型的内容。使用捆绑的 Web 界面（迁移 UI 模块）或包含的 Drush 命令（强烈推荐）导入和回滚内容。