问题描述

我正在构建一个具有一个核心应用程序和许多内容页面的新网站.内容页面大多是动态的，我需要一种方法来定期管理这些动态内容.核心应用程序的主要功能是一个 3 步过程，即读取用户数据(输入页面)、从 MySQL 读取数据(产品页面)以及将应用程序提交到电子邮件地址(应用程序页面).

理想情况下，我想用常规 PHP 构建核心应用程序，并利用 Drupal 的内容管理功能.Drupal 和常规 PHP 可以像我建议的那样轻松集成吗?我的感觉是，将核心应用程序编码为 Drupal 模块会增加复杂性，这些层从一开始就很难编码，并且随着系统的成熟而在以后维护 - 所以我真的很想只使用常规的 PHP.

让我解释一下动态内容(由 CMS 管理)与核心应用程序的交叉点:

常见问题数据等动态内容既用于普通"帮助页面，也用于显示在核心应用程序页面右侧栏下方的迷你提要中.在此列中，从数据库中提取了 3 个随机问题并显示为提要.当用户点击 FAQ 问题时，他们不会离开核心应用程序产品页面，而是在显示问题和答案的弹出窗口中显示数据.此外，用户可以通过此弹出窗口中的简单导航菜单浏览其他问题和答案.我在核心应用程序产品页面上需要 3 个类似的提要，如上所述.

那么，就动态内容管理和核心应用程序编码的易用性而言，就保持简单"而言，这里的理想解决方案是什么?常规 PHP"和 Drupal 可以和平"共存吗?如果是这样，这在技术上是如何可能的?因为在核心应用程序页面中包含了一些由 Drupal 管理的内容，所以核心应用程序还能用普通的 PHP 编码吗?

有什么建议/建议吗?谢谢！吉姆.

这是我几年前提交的帖子的一部分.不幸的是，链接的文章早已不复存在，但它可能仍然与您的需求相关:
将旧式独立 PHP 脚本导入 Drupal 系统
Drupal 系统是一个非常强大的 CMS，但是使用现有的 PHP 站点并试图将其强制使用 Drupal 可能是一件困难的事情.将站点转换为 Drupal 的正确"方式是将其Drupalize"，这意味着以Drupal 方式"做所有事情，这确实是正确的做法 - 但在某些情况下并不是每个人都同意这一点.

我有一个公司的例子，该公司拥有许多基于 HTML/PHP 的网站.他们听说了 Drupal 的灵活性和力量，并决定这是他们的革命选择.但是，另一方面，他们不想改变任何事情，我会尽快完成.

做到这一点的正确方法"是将每个 PHP 脚本分解成各个部分，找到共同点，使用现有的 Drupal 模块创建正确的方法，并使用我自己的附加模块来弥补差距.

但这不是他们要求我做的 - 相反，我寻找一种方法将现有的 PHP 脚本导入到 Drupal 环境中.

搜索现有的解决方案让我获得了概念验证 由 Dan Morrison 描述.归根结底，它使用 PHP 输出缓冲命令来收集旧脚本所做的一切，然后将其显示为 Drupal 模块的一部分.就我而言，我必须进行一些小的修改(主要是将请求中的变量传递给相关范围内的 PHP)，但归根结底，它完全满足了我的需求.嗯，几乎......在其他情况下，我想从 Drupal 的 Form API 中受益，我以不同的方式处理它，我将在后面描述.

I'm building a new website which has one core application and many content pages. Content pages are mostly dynamic and I require a way to manage this dynamic content on a regular basis. The core application's main functionality is a 3 step process or reading user data (input page), reading data from MySQL (product page) and submitting an application to an email address (application page).

Ideally I would like to build the core application in regular PHP and leverage Drupal for its content management capabilities. Can Drupal and regular PHP be integrated as I suggest easily? My feeling is that coding the core application as a Drupal module(s) will add layers of complexity that could be difficult to code from the outset and maintain later on as the system matures - so I would really like to just use regular PHP.

Let me explain where dynamic content (managed by the CMS) intersects with the core application:

Dynamic content such as FAQ data is used both on the 'normal' help pages and also within a mini-feed displayed within core application pages down a right hand side column. In this column, 3 random questions are pulled from the database and displayed as a feed. When users click on FAQ question they are not taken away from the core application product page but are instead shown data in a pop-up window displaying the question and answer. In addition, users can browse other questions and answers through a simple navigation menu within this popup. There are 3 such like feeds as I describe above that I require on the core application product page.

So, what is the ideal solution here in terms of 'keeping things simple' for both the management of dynamic content and the ease of coding the core application? Can 'regular PHP' and Drupal co-exist 'peacefully'? If so, how is this technically possible? Because there is some content managed by Drupal contained within core application pages, can the core application still be coded in regular PHP?

Any advice / suggestions? Thank you! Jim.

This is part of a post I submitted few years ago. Unfortunately the linked article is long gone, but it might still be relevant for your needs:
Importing old-style standalone PHP scripts into Drupal system
Drupal system is a very strong CMS, but taking an existing PHP site and trying to force it on Drupal might be a hard thing to do. The "right" way to convert a site into Drupal is to "Drupalize" it, which means to do everything "the Drupal way", which is really the right thing to do - but is some cases not everybody agrees about that.

I had an example with a company that has many HTML/PHP based sites. They heard about the flexibility and strength of Drupal, and decided it is their choice for the revolution. But, on the other hand, they want not to change anything, and that I will do it as fast as possible.

The "right way" to do it was to break each PHP script they have to its pieces, find the commons, create the right methodology with existing Drupal modules, and finish the gaps with my own additional module.

But this is not what they asked me to do - instead, I looked for a way to just import the existing PHP script into Drupal environment.

Searching for am existing solution brought me to a proof-of-concept described by Dan Morrison. In the bottom line it uses PHP output buffering commands it order to collect everything the old script does, and then to display it as part of a Drupal module. In my case I had to make some small modifications (mainly to pass variables from the request to the PHP in the relevant scope), but in the bottom line it did exactly what I needed. Well, almost... In other cases, in which I wanted to enjoy from Drupal's Form API, I handled it differently, as I will describe later on.

这篇关于Drupal &常规 PHP 集成的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持跟版网！