tag data cache php drupal drupal-7

php - data - drupal add meta tag



¿Cómo funciona Drupal? (9)

Aprendí muchas cosas importando el código drupal .php en un proyecto de NetBeans. A continuación, puede ejecutar el depurador netbeans y ver las diferentes fases de la página se unen.

¿Podría alguien proporcionar una descripción arquitectónica del flujo de control de Drupal 7? Tal vez en el sentido de un diagrama de flujo sobre cómo se genera una página. ¿Qué recursos adicionales sugeriría consultar con respecto a cómo funciona Drupal?

Depende de cuán profundo sea el entendimiento que está buscando; si tiene un buen conocimiento de php, le sugiero que lea el código en sí, comenzando con index.php, y luego pasando a includes / bootstrap.inc, y luego a algunos de los otros scripts en ese directorio.

La clave incluye archivos:

  • menu.inc es muy importante para comprender cómo funciona el sistema en general, ya que maneja una gran cantidad de la asignación implícita de URL al contenido.
  • common.inc tiene la mayoría de las funciones misteriosas que forman la base de la API.
  • module.inc maneja las invocaciones de gancho que Eaton menciona
  • form.inc trata con visualización de formularios, presentación y procesamiento
  • theme.inc maneja la presentación.

También hay alguna funcionalidad clave en los módulos / directorio; en particular, modules / node / node.module forma la base del sistema de nodo, que es en general lo que se usa para encapsular el contenido del sitio.

El código es, en general, muy comentado y claro. El uso de marcado Doxygen dentro de los comentarios significa que el código es efectivamente la documentación canónica.

También ayuda hacer esto usando un editor que puede saltar rápidamente a la definición de una función. Usar vim en combinación con ctags funciona para mí; usted tiene que decirle a ctags que indexe los archivos .inc, .module, etc. como archivos php.

Drupal puede ser confuso en este frente, en parte porque tiene una pila de funciones relativamente profunda. Aunque se trata de PHP de procedimiento, es puramente un evento / oyente impulsado en su arquitectura, y no hay un simple "flujo" en el script PHP principal para que puedas verlo. Hace poco hice una presentación sobre este tema , y las diapositivas se publican en slideshare, pero un resumen rápido de alto nivel puede ser útil.

  • El archivo index.php de Drupal funciona como un controlador frontside. Toda la página se canaliza a través de ella, y la url / ruta "real" que el usuario solicitó se pasa a index.php como parámetro.
  • El sistema de enrutador de ruta de Drupal (MenuAPI) se utiliza para hacer coincidir la ruta solicitada con un módulo de complemento determinado. Ese módulo de complemento es responsable de crear el "contenido principal" de la página.
  • Una vez que se genera el contenido de la página principal, index.php llama al tema (''página'', $ contenido), lo que desvía el contenido al sistema de tematización / despellejado de Drupal. Allí, está envuelto en barras laterales / encabezados / widgets / etc.
  • La página renderizada se devuelve a apache y se envía de vuelta al navegador del usuario.

Durante todo ese proceso, los módulos de plugins de Drupal y de terceros lanzan eventos y los escuchan para que respondan. Drupal llama a esto el sistema ''gancho'', y se implementa mediante convenciones de nomenclatura de funciones. El módulo ''blog'', por ejemplo, puede interceptar ''usuario'' relacionado al implementar una función llamada blog_user (). En el lenguaje de Drupal, eso se llama hook_user () .

Es un poco torpe, pero debido a una peculiaridad de PHP (mantiene una tabla hash interna de todas las funciones cargadas), permite que Drupal compruebe rápidamente si hay oyentes simplemente al iterar sobre una lista de complementos instalados. Para cada complemento, puede llamar a function_exists () en el patrón apropiadamente nombrado y llamar a la función si existe. ("Estoy disparando el evento de" inicio de sesión. ¿Existe la función ''mymodule_login''? Lo llamaré. ¿Existe ''yourmodule_login''? ¿No? ¿Qué tal ''nextmodule_login''? ", Etc.) De nuevo, un toque raro pero funciona bastante bien

Todo lo que sucede en Drupal ocurre debido a uno de esos eventos que se disparan. El MenuAPI solo sabe sobre qué URL / rutas manejan los diferentes módulos de complementos porque activa el evento ''menú'' (hook_menu) y recopila todos los módulos de complemento de metadatos con los que responden. ("Me ocuparé de las noticias de la url / reciente", y aquí está la función para llamar cuando se debe generar esa página ... ") El contenido solo se guarda porque FormAPI de Drupal es responsable de crear una página y los incendios el evento ''se envió un formulario'' para un módulo al que responder. El mantenimiento por horas ocurre porque se activa hook_cron () y se llamará a su función a cualquier módulo con mymodulename_cron () como nombre de función.

Todo lo demás es, en última instancia, solo detalles: detalles importantes, pero variaciones sobre ese tema. index.php es el controlador, el sistema de menús determina qué es la "página actual" y se desencadenan muchos eventos en el proceso de creación de esa página. Los módulos de complementos pueden conectarse a esos eventos y cambiar el flujo de trabajo / suministrar información adicional / etc. Esa también es una de las razones por las que muchos recursos de Drupal se enfocan en hacer módulos. Sin módulos, Drupal no hace más que decir: "¡Alguien pidió una página! ¿Existe? ¿No? OK, voy a servir un 404. ''

La respuesta de Eaton proporciona una buena descripción general. (Soy nuevo aquí, así que no puedo modificarlo, por lo tanto, el comentario).

El momento brutal de "aha" para mí fue darme cuenta de que todo pasa a través de index.php, y luego a través de la cascada de módulos (primero el núcleo, luego el sitio). Para extender la funcionalidad central, no la reescriba. En su lugar, copie el módulo en / sites / all / modules / o / sites / [yoursite] / modules y extiéndalo, o cree un nuevo módulo en esos lugares. Lo mismo para los temas. Los directorios de módulos también pueden contener código de visualización, en forma de tpl, css, etc.

Si estás acostumbrado a restringir marcos de tipo MVC como Rails, Django, etc., todo esto se vuelve un poco confuso. Los módulos pueden mezclar una gran cantidad de código de visualización, y si estás mirando módulos o plantillas de otra persona terminarás caminando hacia atrás a través de la pila. Esa es la belleza / dolor de trabajar en PHP.

Irónicamente, "simplemente crea una aplicación" podría ser la peor forma de aprender esto. Drupal hace tantas cosas fuera de la caja que es simplemente oscuro hasta que descubres el flujo de control. No hay nada en un archivo tpl que le indique por ejemplo dónde viene una función con un nombre divertido como l ().

Los mejores libros sobre el tema son "Desarrollo Pro Drupal" y "Uso de Drupal".

"Pro Drupal Development" incluye varios diagramas de flujo agradables y resúmenes exhaustivos de cada una de las API de Drupal (formularios, tematización, etc.). Está destinado a ser especialmente instructivo para las personas que crean sus propios módulos y temas, pero tiene un gran valor para el desarrollador promedio experto en PHP que quiere entender a Drupal. Además de eso, he creado un módulo personalizado para cada sitio que he creado, solo para obtener un control adicional sobre cosas como ocultar selectivamente campos en varios formularios (lo que generalmente quiere hacer con el fin de simplificar los formularios de nodo para el final). usuarios), por lo que es bueno tener este conocimiento bajo tu sombrero.

"Using Drupal" está dirigido al desarrollador del sitio que quiere saber cómo crear cosas buenas, como galerías, blogs y sitios de redes sociales. Pasa por varios casos de uso y muestra cómo configurar los módulos existentes para hacer cada trabajo. En el proceso, se familiariza con los módulos complementarios esenciales "Content Construction Kit" (CCK) y "Vistas", cómo crear bloques y plantillas personalizados, y las ventajas y desventajas de mantener un sitio Drupal. Recomiendo este libro especialmente para aquellos que quieren ponerse al día y usar Drupal de inmediato. En el proceso, obtienes una comprensión de la organización interna de Drupal.

Nuevo colaborador aquí, 2 años tarde en la conversación ;-)

En respuesta a https://.com/a/1070325/1154755

Para extender la funcionalidad central, no la reescriba. En su lugar, copie el módulo en / sites / all / modules / o / sites / [yoursite] / modules y extiéndalo, o cree un nuevo módulo en esos lugares. Lo mismo para los temas.

En realidad, nunca tuve que copiar un módulo principal para actualizarlo. Drupal Hooks debería ser todo lo que necesitas.

Para los temas, sí, a veces es la única manera de hacerlo, pero a menudo, puedes construir un subtema para obtener el resultado que necesitas.

This (para Drupal 6) y this (para Drupal 7) es una muy buena descripción arquitectónica de drupal. Si desea más detalles, entonces comenzaría a escribir algo. La mayoría de la documentación es buena. Tratar de aprenderlo con un alto nivel de detalle sin algo concreto que lograr será mucho más difícil que probar algo.

Para comprender cómo funciona Drupal, debes comprender el mecanismo de publicación de páginas de Drupal.

En resumen, todas las llamadas / urls / solicitudes son atendidas por index.php que carga Drupal al incluir varios archivos / módulos de inclusión y luego llama a la función apropiada, definida en el módulo, para atender la solicitud / url.

Aquí está el extracto del libro, Pro Drupal Development, que explica el proceso de arranque de Drupal,

El proceso Bootstrap

Drupal se inicia automáticamente en cada solicitud pasando por una serie de fases de arranque. Estas fases se definen en bootstrap.inc y continúan como se describe en las siguientes secciones.

Inicializar la configuración

Esta fase rellena la matriz de configuración interna de Drupal y establece la URL base ($ base_url) del sitio. El archivo settings.php se analiza mediante include_once () y cualquier variable o sobrescritura de cadena establecida allí se aplica. Consulte las secciones "Modificaciones de variables" y "Modificaciones de cadena" de los sitios de archivos / all / default / default.settings.php para obtener más información.

Caché de página inicial

En situaciones que requieren un alto nivel de escalabilidad, es posible que sea necesario invocar un sistema de almacenamiento en caché antes de que se intente siquiera una conexión a la base de datos. La fase de caché de página temprana le permite incluir (con include ()) un archivo PHP que contiene una función llamada page_cache_ fastpath (), que toma el control y devuelve el contenido al navegador. La memoria caché de la página inicial se habilita estableciendo la variable page_cache_fastpath en TRUE, y el archivo que se debe incluir se define estableciendo la variable cache_inc en la ruta del archivo. Consulte el capítulo sobre almacenamiento en caché para ver un ejemplo.

Inicializar base de datos

Durante la fase de la base de datos, se determina el tipo de base de datos y se establece una conexión inicial que se utilizará para las consultas de la base de datos.

Nombre de host / control de acceso basado en IP

Drupal permite la prohibición de hosts en base a nombre de host / IP. En la fase de control de acceso, se realiza una comprobación rápida para ver si la solicitud proviene de un host prohibido; si es así, se niega el acceso.

Inicializar el manejo de la sesión

Drupal aprovecha el manejo de sesiones integrado de PHP, pero anula algunos de los manejadores con los propios para implementar el manejo de sesión respaldado por la base de datos. Las sesiones se inicializan o se restablecen en la fase de la sesión. El objeto $ usuario global que representa al usuario actual también se inicializa aquí, aunque para la eficacia no todas las propiedades están disponibles (se agregan mediante una llamada explícita a la función user_load () cuando sea necesario).

Caché de página tardía

En la última fase de caché de página, Drupal carga suficiente código de soporte para determinar si se va a servir o no una página desde el caché de página. Esto incluye combinar la configuración de la base de datos en la matriz que se creó durante la fase de configuración de inicialización y cargar o analizar el código del módulo. Si la sesión indica que la solicitud fue emitida por un usuario anónimo y el almacenamiento en caché de la página está habilitado, la página se devuelve desde el caché y la ejecución se detiene.

Determinación del idioma

En la fase de determinación del idioma, se inicializa el soporte multilingüe de Drupal y se toma una decisión sobre qué idioma se utilizará para servir a la página actual en función de la configuración del sitio y del usuario. Drupal admite varias alternativas para determinar el soporte de idioma, como el prefijo de ruta y la negociación de lenguaje a nivel de dominio.

Camino

En la fase de ruta, se carga el código que maneja las rutas y el alias de ruta. Esta fase permite que las URL legibles por humanos se resuelvan y gestiona el caché y las búsquedas internas de la ruta de Drupal.

Completo

Esta fase completa el proceso de arranque cargando una biblioteca de funciones comunes, soporte de tema y soporte para mapeo de devolución de llamada, manejo de archivos, Unicode, kits de herramientas de imágenes PHP, creación y procesamiento de formularios, manejo de correo, tablas ordenables automáticamente y paginación de conjuntos de resultados. El controlador de error personalizado de Drupal está configurado y todos los módulos habilitados están cargados. Finalmente, Drupal desencadena el enganche init, de modo que los módulos tienen la oportunidad de ser notificados antes de que comience el procesamiento oficial de la solicitud.

Una vez que Drupal ha completado el arranque, todos los componentes del marco están disponibles. Es hora de tomar la solicitud del navegador y entregarla a la función PHP que lo manejará. El mapeo entre las URL y las funciones que las manejan se lleva a cabo utilizando un registro de devolución de llamada que se encarga tanto de la asignación de URL como del control de acceso. Los módulos registran sus devoluciones de llamada usando el menú de gancho (para más detalles, vea el Capítulo 4).

Cuando Drupal ha determinado que existe una devolución de llamada a la que se correlaciona correctamente la URL de la solicitud del navegador y que el usuario tiene permiso para acceder a esa devolución de llamada, el control pasa a la función de devolución de llamada.

Procesando una solicitud

La función de devolución de llamada hace todo el trabajo necesario para procesar y acumular los datos necesarios para cumplir con la solicitud. Por ejemplo, si se recibe una solicitud de contenido, como http://example.com/ q = nodo / 3, la URL se asigna a la función node_page_view () en node.module. El procesamiento posterior recuperará los datos para ese nodo de la base de datos y los colocará en una estructura de datos. Entonces, es hora de adorar.

Tematizando los datos

La temática implica transformar los datos que se han recuperado, manipulado o creado en HTML (o XML u otro formato de salida). Drupal usará el tema que el administrador haya seleccionado para darle a la página web el aspecto y la sensación correctos. El resultado resultante se envía al navegador web (u otro cliente HTTP).