2010-05-05 2 views
2

Я создаю новый веб-сайт, в котором есть одно основное приложение и множество страниц контента. Страницы контента в основном динамичны, и мне необходим способ управления этим динамическим контентом на регулярной основе. Основной функциональностью основного приложения является трехэтапный процесс или чтение пользовательских данных (входная страница), чтение данных из MySQL (страница продукта) и отправка приложения на адрес электронной почты (страница приложения).Drupal & Regular PHP Integration

В идеале я хотел бы создать основное приложение в обычном PHP и использовать Drupal для его возможностей управления контентом. Может ли Drupal и регулярный PHP быть интегрированным, как я предлагаю легко? Я чувствую, что кодирование основного приложения, поскольку модуль (-ы) Drupal добавит уровни сложности, которые могут быть трудно скомпилировать с самого начала и впоследствии поддерживать, когда система созревает, поэтому я бы очень хотел просто использовать обычный PHP.

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

Динамический контент, такой как FAQ данных используется как на «нормальных» страниц помощи, а также в мини-ленты отображается внутри основных страниц приложения вниз по правой колонке. В этой колонке 3 случайные вопросы вытаскиваются из базы данных и отображаются в виде фида. Когда пользователи нажимают на вопрос FAQ, они не удаляются с основной страницы продукта приложения, а отображаются во всплывающем окне, отображающем вопрос и ответ. Кроме того, пользователи могут просматривать другие вопросы и ответы через простое меню навигации в этом всплывающем окне. Есть 3 таких типа, как я описываю выше, которые требуются на странице продукта основного приложения.

Итак, что является идеальным решением в плане «простого хранения» как для управления динамическим контентом, так и для простоты кодирования основного приложения? Может ли «обычный PHP» и Drupal сосуществовать «мирно»? Если да, то как это технически возможно? Потому что есть некоторый контент, управляемый Drupal, содержащийся на страницах основных приложений, может ли основное приложение по-прежнему кодироваться в обычном PHP?

Любые советы/предложения? Спасибо! Джим.

ответ

0

Похоже, вы спрашиваете о двух вещах:

  1. включая содержимое Drupal в качестве заказного приложения PHP.
  2. Отображение содержимого Drupal во всплывающем окне из приложения PHP.

Есть целый ряд различных уровней integration- если ваша потребность так же просто, как вытягивать содержимое на странице, то вы можете просто создать представление (http://drupal.org/project/views) с этим содержимым из Drupal, что вы можете сделать доступный, а затем включить его в ваше веб-приложение.

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

+0

Hi Chris, спасибо за ваш ответ. Не могли бы вы расширить немного, когда вы скажете следующее: «Если ваша потребность так же просто, как вытащить содержимое на страницу, тогда вы сможете просто создать представление (http://drupal.org/project/views) с этим контент из Drupal, который вы можете сделать доступным, а затем включить его в свое веб-приложение ». В этом случае большинство моего кода в Drupal и основное приложение на регулярной основе PHP? Я не совсем понимаю архитектуру, стоящую за ней, чтобы увидеть, как и обычный PHP-скрипт, и модуль просмотра Drupal могут выполняться с 1 'страницы'. – user333128

1

Это часть сообщения, которое я представил несколько лет назад. К сожалению, связана статья уже давно нет, но он все еще может иметь значение для ваших нужд:
Импорт старого стиля автономной PHP скриптов в системе Drupal
система Drupal является очень сильным CMS, но принимая существующий PHP сайт и пытается заставить его на Drupal быть трудным делом. «Правильный» способ конвертировать сайт в Drupal - это «Drupalize», что означает делать все «Drupal way», что действительно нужно делать, но в некоторых случаях не все согласны с этим.

У меня был пример с компанией, которая имеет множество сайтов на основе HTML/PHP. Они слышали о гибкости и силе Drupal и решили, что это их выбор для революции. Но, с другой стороны, они хотят ничего не менять и что я сделаю это как можно быстрее.

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

Но это не то, что они просили меня сделать, вместо этого я искал способ просто импортировать существующий PHP-скрипт в среду Drupal.

Поиск существующего решения привел меня к proof-of-concept, описанному Dan Morrison. В нижней строке он использует команды буферизации вывода PHP, которые он заказывает, чтобы собрать все, что делает старый скрипт, а затем отобразить его как часть модуля Drupal. В моем случае я должен был внести небольшие изменения (главным образом, чтобы передавать переменные из запроса на PHP в соответствующей области), но в нижней строке он сделал именно то, что мне нужно. Ну, почти ... В других случаях, когда я хотел наслаждаться API-интерфейсом Drupal, я обрабатывал его по-другому, как я опишу ниже.

+0

Доказательство ссылки на концепцию не работает. Вот ссылка на архив: https://web.archive.org/web/20070218204229/http://coders.co.nz/drupal_development/?q=node/547 –