php - query - joomla consulta base de datos
GeneraciĆ³n de pĆ”ginas web(CMS like) (4)
Para fines de aprendizaje, decidí averiguar cómo los CMS como Joomla generan páginas web. El hecho de que no haya páginas físicas me hace sentir incómodo. Quiero decir que no puedes encontrar about.html
o contacts.html
páginas web en tu hosting mientras usas Joomla, todo lo que tienes es una gran cantidad de archivos PHP que generan la página que necesitas de MySQL (supongo).
Me gustaría entender cómo funciona esto? ¿Qué hace Joomla cuando alguien va a http://example.com/about.html
por ejemplo? Si no hay una página about.html
en mi directorio, ¿cómo genera Joomla la página que necesito cuando alguien pasa por este enlace?
No puedo formular una pregunta breve, debido a la falta de conocimiento en este tema, por eso Google no me ayudó mucho, así que sería genial que alguien me diga dónde debo buscar o empiece y un ejemplo rápido .
Quiero al menos poder crear una página, que PHP genera cuando el usuario va a example.com/topic.php
y sabe cómo funciona.
UPD: ¿Necesito esto por el bien de SEO, o también están bien las páginas estáticas simples?
Joomla es un sistema de gestión de contenido, por lo tanto, para poder administrar el contenido, se almacena en una base de datos en lugar de tener archivos html separados. todo, ya sea contenido, elementos de menú, nombres de extensiones, etc. se almacenan en tablas de bases de datos. Con Joomla, tienes 1 archivo index.php principal al que se aplica una aplicación, y todo. Joomla usa MVC (Modelo-Vista-Controlador). A continuación hay pequeños resúmenes de lo que son ( fuente )
- Un modelo, que representa la estructura lógica subyacente de los datos en una aplicación de software y la clase de alto nivel asociada a ella. Este modelo de objetos no contiene información sobre la interfaz de usuario.
- Una vista, que es una colección de clases que representan los elementos en la interfaz de usuario (todas las cosas que el usuario puede ver y responder en la pantalla, como botones, cuadros de visualización, etc.)
- Un controlador, que representa las clases que conectan el modelo y la vista, y se utiliza para comunicarse entre clases en el modelo y la vista.
Las URL''S que ve, como http://example.com/about.html , son SEF (Search Engine Friendly) y se generan a través del núcleo de Joomla. Una URL estándar puede parecer algo así para un artículo:
http://www.example.com/index.php?option=com_content&view=article&id=1
Para obtener más información detallada sobre qué es Joomla, lea esto:
http://www.joomla.org/about-joomla.html
Espero que esto ayude
La mayoría de los sistemas CMS que no son de formato plano utilizan un tipo de sistema MVC o, como mínimo, un sistema de plantillas.
Por ejemplo, Wordpress tampoco tiene páginas específicas para cada publicación o página, sino que mantiene las cosas en el DB que permite una administración más fácil para el usuario, y temas para acceder fácilmente y cambiar los datos para que quepan en la ''vista'' (o plantilla en Caso de WP).
La mayoría de las plataformas CMS hacen esto por una variedad de razones, todas las cuales se relacionan con
- Facilidad de gestión. Las plataformas CMS proporcionan herramientas para editar fácilmente el contenido sin tener que acceder al sistema de archivos y cambiar el archivo real.
- Facilidad de integración dentro de los cambios de UI.
- Posibilidad de exportar el sistema y adaptarse a nuevos entornos. Es mucho más fácil cargar una exportación de Base de datos que unos cientos de archivos y carpetas y esperamos hacerlo bien.
Recuerdo cuando comencé a usar CMSes después de hacer páginas estáticas durante muchos años y la falta de archivos html también me resultaba realmente extraña. http://docs.joomla.org/Where_are_the_web_pages%3F
Joomla, como la mayoría de las aplicaciones web modernas (también conocidas como "web 2.0"), separa la presentación del contenido.
Esto es simplificador, por supuesto, pero ...
El contenido se almacena en una base de datos. La presentación se gestiona mediante la plantilla (ya sea por defecto de Joomla o por el reemplazo de las diversas partes).
Joomla es un software que, en respuesta a una solicitud de página, reúne su contenido y presentación y la devuelve, más comúnmente como HTML enviado a un navegador. Joomla te ayuda a administrar la construcción de páginas complejas y dinámicas y reduce o elimina la necesidad de crear páginas a mano, pero aún así te permite construir tantas manos como desees, solo de una manera diferente.
PHP como lenguaje fue creado con esta idea en mente.
Cuando Joomla crea una página web para poner en su navegador, hace varias cosas (simplificando de nuevo). Carga el index.php de su plantilla desde la carpeta de plantillas. Esto le da a la página su estructura básica. Si busca en ese archivo verá las etiquetas familiares <html><head></head><body></body></html>
tal como lo haría en una página estática. También verá css y javascript incluidos, pero no de forma HTML normal, sino de una manera que se modifica para hacerlo más flexible. Lo mismo con los metadatos, Joomla va a juntar metadatos de diferentes lugares (la configuración de su sitio, un artículo específico, etc.) de una manera flexible en lugar de escribirlos por separado en el archivo.
Una vez que llega al <body>
Joomla comienza a incorporar datos y diseños html. Realiza consultas a diferentes partes de la base de datos para obtener, por ejemplo, el texto de su artículo, su lista de enlaces para el (los) menú (es), para encontrar las etiquetas más populares y demás, básicamente los datos que desee en su página.
A continuación, obtiene lo que llamo diseños que son básicamente los archivos que definen el html para partes más pequeñas de la página (como el texto del artículo, el menú, la lista de las etiquetas más populares). Estos están un poco extendidos, pero joomla los busca primero en la carpeta html de su plantilla (ejemplos de plantillas / beez3 / html) y si no están allí, busca en las carpetas tmpl que verá dentro de las carpetas de vistas de los componentes y módulos. En la actualidad, algunos elementos compartidos de diseños también se encuentran en la carpeta de diseños que encontrará en el nivel superior, pero estos se llaman desde los otros diseños, nunca directamente. Entonces, en el caso de esta página con un artículo, un menú y un módulo de etiquetas populares, obtendrá los diseños de
- / components / com_content / views / article / tmpl
- / modules / mod_menu / tmpl
- / modules / mod_tags_popular / tmpl
o cualquier reemplazo para estos que coloque en la carpeta html de su plantilla. Ahora Joomla básicamente toma los diseños y donde dicen que lo hagan, reemplaza las variables de PHP con los datos de su base de datos. Entonces en las etiquetas populares obtenemos un código como este
<ul >
<?php foreach ($list as $item) : ?>
<li><?php $route = new TagsHelperRoute; ?>
<a href="<?php echo JRoute::_(TagsHelperRoute::getTagRoute($item->tag_id . ''-'' . $item->alias)); ?>">
<?php echo htmlspecialchars($item->title); ?></a>
<?php if ($display_count) : ?>
<span class="tag-count badge badge-info"><?php echo $item->count; ?></span>
<?php endif; ?>
</li>
<?php endforeach; ?>
</ul>
Entonces ves <ul></ul>,<li></li><span></span>
y <a></a>
que esperarías en html pero vemos que estamos usando PHP para automatizar cosas como obtener el texto del título ($ item-> title) o la cantidad de veces que se ha usado una etiqueta ($ item-> count) o la url echo JRoute :: _ (TagsHelperRoute :: getTagRoute ($ item-> tag_id. ''-''. $ item-> alias)); que es donde Joomla está administrando el enrutamiento y generando la URL SEF. Y es por eso que utilizamos un CMS, para poder automatizar todas esas tareas para que podamos tener miles de páginas, todas administradas por solo unos pocos archivos.
Ahora, hay excepciones y variaciones en lo anterior. Por ejemplo, puede obtener sus datos de un archivo o de un servicio web, puede devolver json en lugar de html, etc., pero ese es el principio básico. Separar la presentación del contenido, darle al diseñador control sobre la presentación pero hacerlo de modo que no tenga que preocuparse por el contenido, hacerlo de modo que el creador del contenido no tenga que preocuparse por el diseño, hacerlo para que el desarrollador no lo haga También tengo que preocuparme por eso, hacerlo lo suficientemente simple como para que un webmaster que use los tres sombreros pueda resolverlo.
Ahora, para generar la página que desea ... Joomla nunca creará una url con php al final en la forma en que lo tiene. Siempre tendrá una extensión o una extensión que elija en la configuración global, generalmente .html o .htm. Entonces, digamos que quieres topic.html. Diríjase al administrador y asegúrese de haber activado todas las funciones de SEF (y copiado htaccess.txt en .htaccess o agregado a su .htaccess existente). Luego ve al gerente de artículos y crea un artículo. Luego vaya al administrador de menú y al menú principal. Cree un enlace de menú de elemento único al artículo con el que creó y cree el alias "tema". Ahora ve al frente de tu sitio y actualiza. Haga clic en su nuevo enlace de menú.
Ok, entonces la pregunta es qué sucede cuando Joomla envía una solicitud en forma de una URL SEF. Entonces, pretendamos que no estás usando las URL de SEF, sino que tienes algo como index.php? Option = com_content & view = article & id = 7 ... en ese caso podemos ver lo que sucede, vamos al contenido_com, el artículo MVC y el model va a usar el id de 7 para hacer su consulta y lo que encuentra en el archivo de vistas de artículos / article / tmpl / default.php para hacer el html. Si entiendo lo que estás preguntando. Así que eso es bastante obvio, obtenga los datos de la url publicada, ejecute la consulta, devuelva el html. Entonces, como preguntas con razón, ¿qué pasa cuando no tenemos eso? Esa es una de las piezas más difíciles, complejas y discutidas sobre Joomla y muchos otros sistemas. Esto se debe a que cuando tienes archivos físicos tienen nombres claros y están claramente organizados en carpetas jerárquicas. Por lo tanto, cuando construye una página estática, controla completamente la url de un archivo dando un nombre al archivo y luego colocándolo en carpetas con nombre. Hay diferentes maneras de manejar este problema en su sistema. Por ejemplo, si tiene un número finito de páginas / URL, puede crear una tabla de búsqueda o almacenar una lista en caché en un archivo. O puede hacer lo que hace el cms actual, que es tener reglas de configuración que usa para determinar qué es lo que esa url realmente está pidiendo. Entonces, por ejemplo, verá que le dije que haga un elemento de menú con el alias "tema". Eso es porque lo primero que Joomla hace es verificar los elementos del menú con un alias que coincida exactamente con la url. La tabla de elementos del menú contiene la URL dinámica completa correspondiente. Con ese patrón de URL, si no encuentra un alias, le dará un 404. Después de eso, cuando no hay un elemento de menú, encontrar direcciones válidas coincidentes se vuelve mucho más complicado, pero al final es solo un conjunto jerárquico de reglas para verificar
Entonces, la respuesta básica es que hace una búsqueda simple o compleja para que pueda obtener los datos que necesita para que el mvc haga su trabajo. No es simple de ninguna manera y es uno de los buenos argumentos para usar una solución con un historial para resolver este problema.
Te di un voto positivo para esto:
todo lo que tienes archivos php infinito ...
Eso es porque el código de Joomla es terrible. Sin embargo, todos los sistemas de administración de contenido tienen esencialmente los mismos problemas para resolver. El objetivo básico es asociar una URL determinada con una "página" deseada, que es el contenido / diseño / estilo, etc. El panel de administración le permite elegir / crear contenido y asociarlo a una url determinada. El contenido y la configuración se almacenan en la base de datos. Cuando visitas el sitio, en realidad te dirigen a un único archivo php: index.php
. Ese archivo php extraerá otros archivos php que necesita para mirar básicamente la url actual, encontrar el contenido y la configuración para esa url, y mostrar ese contenido con esa configuración.
Una gran parte de su preocupación parece ser el enrutamiento. Consulte mi respuesta aquí para obtener un ejemplo básico de enrutamiento (esto debería ayudarlo mucho): Htaccess y cuentas de usuario
Los sistemas de administración de contenido también suelen permitirle separar el contenido de una página de su diseño. Esto es algo asombroso Si tenía 20 páginas en su sitio y decidió rediseñar el sitio, no tiene que tocar el contenido en absoluto. Considera esto:
<article>
<header>
<h1>{{article.title}}</h1>
<time>{{article.date | date:''mediumDate''}}</time>
<span>by <a href="{{article.authorHref}}">{{article.author}}</a></span>
<p>From: <a href="{{article.categoryHref}}">{{article.category}}</a></p>
<p>{{article.categoryDesc}}</p>
</header>
<section>{{article.content}}</section>
</article>
Esta es una marca de plantilla real de un CMS que estoy creando. Si tengo 20 páginas con artículos, este conjunto de códigos se repetirá en las 20 páginas. Los manillares {{}}
son ganchos para que el contenido se extraiga de la base de datos. Entonces, si quiero cambiar el diseño del artículo, podría abrir este archivo de plantilla y cambiarlo a algo así como:
<article>
<section>{{article.content}}</section>
<footer>
<h1>{{article.title}}</h1>
<time>{{article.date | date:''mediumDate''}}</time>
<span>by <a href="{{article.authorHref}}">{{article.author}}</a></span>
<p>From: <a href="{{article.categoryHref}}">{{article.category}}</a></p>
</footer>
</article>
¡Esto sin duda sería mejor que tener que cambiar el código en 20 archivos! Muchas cosas en un CMS son plantillas: todo el sitio, así como las piezas de contenido individuales (complementos) como un feed de Twitter, etc.
En cuanto a SEO
Los rastreadores SEO solo ven la fuente de la página. En ese punto, no hay diferencia con respecto a las páginas estáticas y las páginas generadas por CMS.
Urls
Una gran ventaja de usar un CMS es que puede hacer cumplir los principios de SEO. En primer lugar, para obtener las URL de SEO, debe implementar algún tipo de enrutamiento para que sus URL se vean como site.com/about
lugar de site.com/about.html
. Un buen CMS tendrá esto incorporado.
Metaetiquetas
Mientras que las etiquetas <meta>
son menos importantes ahora de lo que solían ser, aún así pueden ser útiles. Un CMS debería generar automáticamente esto para usted en función de la configuración predeterminada con anulaciones opcionales para cada página si las configura en el panel de administración. Podría argumentar que esto garantiza que haya meta en cada página y que no esté sujeto a olvido.