Unlimited Plugins, WordPress themes, videos & courses! Unlimited asset downloads! From $16.50/m
Advertisement
  1. Code
  2. PHP

Aplique el principio DRY para construir sitios web con ExpressionEngine 2

by
Read Time:18 minsLanguages:

Spanish (Español) translation by Luis Chiabrera (you can also view the original English article)

ExpressionEngine 2 es un maravilloso sistema de administración de contenido y podría decirse que es el CMS más amigable para el diseñador, utilizado por muchos nombres conocidos, como A List Apart, Andy Clarke y Veerle Pieters. Irónicamente, sin embargo, su configuración predeterminada no es adecuada para su uso en un flujo de trabajo de desarrollo web profesional, que generalmente involucra múltiples sitios, servidores y desarrolladores.

Este tutorial le mostrará cómo personalizar ExpressionEngine 2 para que pueda comenzar a ejecutar con un punto de partida sólido pero flexible que puede desplegarse fácilmente en múltiples entornos en minutos.


Visión general

No soy programador. Sin embargo, el mantra de programación no se repite, o el principio DRY para los amantes de las siglas entre nosotros, realmente ha comenzado a resonar en mí a medida que me involucro más tanto en el desarrollo web como en la gestión de mi propio negocio. De hecho, DRY es un buen consejo para vivir tu vida en general. Repetirse cuesta más tiempo por adelantado, y potencialmente mucho más en el futuro si tiene que regresar y hacer el mismo cambio en varios lugares.

Además, es un obstáculo para el crecimiento personal porque si estás haciendo algo que ya has hecho, no estás aprendiendo algo nuevo. Lo que es mejor es identificar los lugares donde se repite y crear un sistema para estandarizar esa tarea o dato.


Una pequeña historia

Cuando comencé a trabajar con ExpressionEngine hace un año y medio, era un proyecto único y yo era un diseñador novato. No hace falta decir que la mentalidad SECO era lo más alejado de mi mente. Estaba felizmente tarareando, manipulando la configuración como lo dictaba la situación, sin documentar nada y divirtiéndome con campos personalizados y grupos de plantillas, esas cosas que hacen que EE el sueño de un diseñador se haga realidad. Fue como mi primera cita con el software. Al final, me gustó tanto EE que decidí ser exclusivo y "casarme" como mi CMS de elección para todos los proyectos futuros.

Sin embargo, después del tercer o cuarto sitio, comencé a ver fallas en nuestra relación (como es probable que suceda cuando realmente te familiarizas con algo) y me frustré haciendo tareas serviles y repetitivas relacionadas con el despliegue y la administración de EE. Esto fue especialmente evidente con algunos proyectos en curso que requirieron dos o tres actualizaciones semanales desde el desarrollo hasta la puesta en escena en servidores en vivo. Llegué al punto de que pasaba casi tanto tiempo administrando implementaciones como en realidad estaba codificando.


La solución

No contento con perder dinero y esclavizarme con el aburrido trabajo pesado, traté de arreglar el desastre.

Lo que sigue es fruto del trabajo de mí y de otros, una guía para aplicar el principio DRY al desarrollo y despliegue de sitios con EE.

Le guía a través de cómo modifiqué y personalicé la configuración predeterminada flácida y sin sentido de ExpressionEngine 2 en un caballo de batalla eficiente y delgado que elimina casi toda la repetición de trabajar con EE. Específicamente, estas modificaciones:

  • Proporcione un punto de partida con todos los complementos de uso común instalados y la configuración activada para que no ejecute el asistente de instalación y comience desde cero todo el tiempo.
  • Integre EE con un sistema de control de versiones de su elección para una implementación rápida en múltiples servidores web o estaciones de trabajo de desarrolladores y una fácil administración del código. Mi experiencia es con SVN, pero todos los principios se aplican a Git también.
  • Centralice todas las configuraciones y configuraciones para facilitar la migración de un servidor a otro, por lo que iniciar y enviar actualizaciones es más fácil que un dolor de cabeza.

Este ha sido un esfuerzo bastante grande y no podría haberlo hecho solo. Muchas gracias a las siguientes personas, que me ayudaron tanto si lo sabían como si no:


Paso 1: Descarga e Instalación

Por su bien, obtenga una copia nueva de la última versión de EE 2 antes de hacer algo de esto. Descargue e instale normalmente, preferiblemente en un servidor local, ya que hará muchos cambios en los archivos. Omita las plantillas de Agile Records cuando se le solicite.

Tome los archivos de ejemplo que se incluyen con este tutorial. Todavía no necesita hacer nada con ellos, pero manténgalos a mano.


Paso 2: Verter la sopa de configuración

Si alguna vez ha tenido que migrar ExpressionEngine de un servidor a otro, sabe que esta tarea no es tarea fácil; de hecho, es una pesadilla completa si no estás preparado. Mucho de esto se debe al hecho de que ExpressionEngine almacena variables de configuración y rutas de servidores en toda la creación, hasta el punto de que es difícil rastrearlas y ajustarlas cuando mueve servidores.

Kenn Wilson, de Corvid Works, lo resume en un inglés mejor que el mío:

“Esto es lo que hace que Expression Engine sea tan inportable: pasar de un servidor a otro, por ejemplo, desde el desarrollo hasta la producción, requiere actualizar esta URL y la información de ruta en literalmente una docena de lugares. Es torpe, lento y propenso a errores ".

Él tiene razón. Afortunadamente, hay otra forma. En lugar de editar todas esas variables en una docena de lugares en el panel de control y probablemente olvidando algunas, puede consolidarlas en un solo lugar: los archivos de configuración. Así es, todos esos campos dispersos en docenas de páginas en su mapa CP a un par de archivos PHP. De manera predeterminada, ExpressionEngine almacena información de configuración de la que tendrá que preocuparse en dos archivos. Estos son:

  • system/expressionengine/config/config.php
  • system/expressionengine/config/database.php

Abandonando database.php

Como se puede imaginar, database.php almacena la información de conexión de la base de datos MySQL. Supongo que EllisLab toma la posición de que es más fácil encontrar la información de la base de datos si está en su propio archivo adecuadamente nombrado, pero voy a argumentar lo contrario. Esto es DRY, ¡maldita sea! Prefiero abrir un archivo y editar mi configuración desde un lugar, no dos, así que eliminé database.php por completo. Bueno, no del todo, pero tomé todas las configuraciones de la base de datos y las moví a config.php con un pequeño PHP.

Cambie el nombre de su archivo database.php existente a algo como old-database.php y muévalo a su escritorio, ya que necesitará la configuración de conexión más adelante. Reemplácelo con la base de database.php incluida en este tutorial y configure los permisos en 400 como se indica.

Felicidades. Nunca más tendrá que preocuparse por database.php nuevamente.

Consolidando config.php

Ahora que database.php le dice a ExpressionEngine que busque la información de conexión de la base de datos en config.php, necesitamos ponerla allí, pero hay un problema. Cuando EE se mueve de un servidor a otro, la configuración de conexión de la base de datos debe cambiar para reflejar el nuevo entorno del servidor. Si queremos desarrollar e implementar EE con un sistema de control de versiones (y confía en mí, lo hacemos), cada vez que implementemos una copia de trabajo en un nuevo servidor, tendremos que descargar una copia de config.php, editar el configuración de la base de datos para que sean correctos para ese servidor, haga una copia de seguridad FTP en el servidor y asegúrese de decirle a nuestro control de versiones que lo ignore cuando emitimos un compromiso o actualización. En el mejor de los casos, tendríamos un archivo de configuración separado, no controlado por versión para cada servidor adicional en el que reside el sitio. Para mí (y soy un espectáculo individual) eso es:

  • Servidor local de iMac
  • Servidor local de Macbook Pro
  • Servidor provisional
  • Servidor en vivo

Agregue otro par de desarrolladores si trabaja en una agencia y está viendo muchos de estos insectores corriendo. Entonces, ¿qué sucede cuando necesita cambiar otra variable de configuración, como el número de licencia? ¿Te envías una copia de este archivo a ti mismo y a otros desarrolladores y la subes a todos los servidores uno por uno? DRY, mis amigos, DRY. La única respuesta lógica es un único archivo config.php controlado por versión que puede acomodar todos los entornos de servidor.

Tonterías, se podría decir, pero gracias a un PHP inteligente es realmente posible. Como puede ver en el siguiente ejemplo, la sintaxis de caso de PHP busca una dirección IP y sirve la configuración de la base de datos adecuada en función de esa IP. Ahora, lo único que necesita saber y cambiar cuando se implementa en un nuevo servidor es la dirección IP y la información de conexión de la base de datos, que debe estar disponible para usted.

En este punto, quiero distinguir entre lo que llamo variables ambientales y variables universales. Las variables ambientales son diferentes en cada entorno de servidor. Las variables universales son las mismas sin importar en qué servidor resida el sitio, por lo que quedan fuera de la sintaxis de conmutador / caso de IP. Estas son cosas como las rutas del servidor y las URL a la carpeta de temas, la carpeta de plantillas, CAPTCHA, el número de licencia, básicamente cualquier cosa además de la información de la base de datos y la dirección IP antes mencionadas (todas están comentadas en el archivo incluido como referencia).

¿Me escuchaste decir que las rutas y las URL del servidor permanecen igual sin importar en qué servidor estés? Si lo hiciste. Mientras la estructura de carpetas de su sitio permanezca igual en todas las instancias (y si está en control de versiones, obviamente lo hará), el config.php personalizado incluido en estos tutoriales usa variables PHP para detectar la ruta del servidor raíz y la URL y completarlas para ti Por qué EE no hace esto para empezar, me desconcierta, pero estoy divagando. Ya no olvides cambiar la ruta del servidor a la carpeta de temas cuando migres servidores y pases una hora descubriendo por qué tienes una pantalla en blanco en lugar de un CP. Alguien emocionado todavía?

Para instalar el archivo config.php personalizado:

  1. Cambie el nombre de su config.php existente, ubicado en system/expressionengine/config/config.php, a algo como old-config.php y muévalo a su escritorio.
  2. Tome el config.php incluido en este tutorial y suéltelo en system/expressionengine/config. Establecer permisos a 400.
  3. Abra su nuevo config.php en su editor de código, junto con old-database.php y old-config.php
  4. Copie y pegue la configuración de los archivos antiguos en el nuevo. El archivo ha sido comentado para que sepa qué poner dónde.

Tenga en cuenta que una variable universal puede convertirse en una variable ambiental si lo necesita. Supongamos que desea cambiar el nombre de su sitio automáticamente en función del servidor en el que se encuentra, por lo que puede saber de un vistazo si está buscando la versión local, de desarrollo o en vivo de su sitio. Simplemente elimine la variable del área "variables universales" y cópiela en cada caso de IP, asignándole el valor que desee.


Paso 3: Limpieza de la casa

Seamos sinceros; la instalación predeterminada de ExpressionEngine incluye muchos archivos que no necesitas, especialmente si eres un desarrollador profesional que no está hurgando por primera vez. Estos incluyen los archivos de tema para el sitio de ejemplo de Agile Records, emoticonos, temas wiki y mucho más. ¿Por qué engordar su sitio innecesariamente? Ponga EE a dieta y elimine todo esto, siempre puede obtener una copia nueva y agregarla nuevamente en el caso poco probable de que la necesite para un wiki, foro u otro sitio basado en la comunidad. Elimina solo lo que tiene sentido para ti, pero he hecho una docena de sitios de EE y nunca he usado ninguno.

  • /themes/wiki_themes
  • /themes/site_themes/agile_records
  • /themes/profile_themes/agile_records
  • /images/smileys
  • /images/avatars

Paso 4: Cree una Estructura de Carpetas de Nivel Superior Estándar y un Archivo .htaccess

Al igual que muchas tareas en el desarrollo web, no hay una forma correcta de hacerlo, pero lo importante es que elija una y seguirla. A algunas personas les gusta poner sus archivos de activos estáticos (imágenes, css, js, swf, etc.) en una carpeta /themes/site_themes/examplesite. Prefiero poner cada carpeta de activos en el nivel superior porque soy vago y no me gusta hacer clic en tres niveles de subcarpetas para acceder a estos archivos durante el desarrollo, además me gustan las URL cortas y agradables en mi HTML y CSS. Ahora que me he acostumbrado a una estructura estándar, no creo archivos o carpetas adicionales de nivel superior a menos que sea absolutamente necesario (verás por qué en un minuto). Así es como se ve mi estructura de nivel superior.

  • .htaccess - explicará más en un minuto
  • system - renombra esto por favor
  • css
  • favicon.ico
  • fw: es la abreviatura de "framework", p. mis imágenes de fondo CSS
  • images - imágenes de contenido no administrado por CMS
  • index.php
  • js
  • robots.txt
  • plantillas
  • themes - CP y temas de tipo de campo
  • uploads - donde van todos los documentos e imágenes administrados por CMS

Ahora me pongo a hablar sobre .htaccess. Para muchos desarrolladores es un misterio y, francamente, también lo es para mí, pero sé lo suficiente como para usarlo para eliminar ese feo index.php de las URL bonitas de EE. Utilizo una variante del método de exclusión de ExpressionEngine Wiki. Esto no garantiza que funcione en su servidor web, pero me ha funcionado en MAMP Pro, HostGator y MediaTemple, tanto (gs) como (dv). Se aplican las advertencias habituales, p. mod_rewrite debe estar habilitado en http.conf de Apache, etc. Si está utilizando este método para eliminar index.php y desea agregar un nuevo archivo o carpeta de nivel superior a su sitio (y me refiero a un archivo o carpeta "real", no una entrada EE, plantilla o grupo de plantillas), necesitará agregar una excepción en .htaccess o de lo contrario ese archivo / carpeta será inaccesible.

Para instalar mi .htaccess personalizado, suelte el archivo incluido llamado temp.htaccess en su carpeta de nivel superior. Elimine la parte "temporal" del nombre de archivo (todo antes del punto). Su sistema operativo podría advertirle que cambiar el nombre del archivo destruirá el universo. Ignora esto y presiona OK. El archivo puede desaparecer, lo cual está bien porque .htaccess es un archivo oculto. Ahora, si desea editarlo, deberá tener archivos ocultos visibles en la configuración de su sistema operativo.


Paso 5: Instale sus complementos predeterminados y configúrelos

Después de desarrollar varios sitios de EE, hay complementos que no estoy dispuesto o no puedo vivir sin ellos. Estos son los mejores que la comunidad de desarrollo de EE tiene para ofrecer y tienen el honor de estar instalados en mi base de código para que cada sitio nuevo los tenga desde el principio. Son (y todos estos son gratuitos):

No solo instale estos, configúrelos. Por ejemplo, configuré todas mis plantillas de notificación por correo electrónico para Freeform, creé campos de formulario personalizados adicionales basados en lo que generalmente uso para un formulario de contacto estándar, y tengo una plantilla llamada contact.html que tiene el código de formulario de front-end. , incluida la validación de JavaScript y un mensaje de éxito. Incluso si necesito agregar un campo o dos, o mover ese código de formulario a una plantilla diferente, es cuestión de retoques, no de crear desde cero todo el tiempo. DRY. Menos el estilo CSS, ese formulario está listo para salir de la caja.

Esté atento a otro artículo mío pronto cuando analice estos y un par de complementos comerciales para EE2 con más detalle.


Paso 6: configure el grupo de miembros de su cliente

Dar acceso ilimitado a mi cliente es aterrador tanto para ellos como para mí.

Esta es una de esas cosas que probablemente te olvides de hacer hasta que casi hayas terminado con el sitio, pero no es necesario que esté en tu código base. La cuenta de administrador de EE predeterminada pertenece al grupo de miembros Super Admins, que necesariamente tiene acceso a todo. Dar acceso ilimitado a mi cliente es aterrador tanto para ellos como para mí, por lo que creo un segundo grupo de miembros llamado Administradores. Por lo general, espero hasta que hayan elegido una dirección de correo electrónico antes de crear su cuenta, pero eso solo toma un par de segundos una vez que se han definido los permisos del grupo de miembros.

En este grupo de miembros, desactivé todo el acceso a las plantillas, el sitio y la administración de miembros, el módulo de comunicación y los complementos. Todo lo que la mayoría de los clientes necesitan hacer es crear y editar contenido, y tal vez ver sus presentaciones de Freeform. Eso es. Simplifica su vida y la tuya y quita lo que no necesitan. Nuevamente, he tenido que ajustar esto antes, pero un punto de partida es mejor que comenzar desde cero.


Paso 7: trabajar con su base de código

Felicitaciones, ahora debería tener un punto de partida muy superior para su próximo proyecto ExpressionEngine. Para que pueda agregarlo y reutilizarlo, cree un nuevo proyecto en su control de versiones y confirme su base de código ExpressionEngine personalizada como la versión número uno. A continuación se muestran ejemplos de algunas operaciones comunes que probablemente deba realizar una vez que tenga nuevos proyectos en proceso (puede variar según la configuración del servidor o si está utilizando Git en lugar de SVN).

Crear un nuevo proyecto: 10 minutos

  • Borre todas las cachés de su proyecto de base de código.
  • Exporte la base de datos e importe con el nuevo nombre del proyecto utilizando PHPMyAdmin o similar.
  • SVN exporta una copia de su base de código a la carpeta de copia de trabajo de un nuevo proyecto SVN. MUY IMPORTANTE: Tenga en cuenta que dije exportar, no pagar.
  • Establezca las siguientes carpetas y sus contenidos en los permisos 777:
    • /plantillas
    • /uploads (o como se llame su carpeta de carga)
    • /system/expressionengine/cache/db_cache
  • Agregue información de conexión de base de datos para la nueva base de datos a config.php. Cambie el nombre del sitio, los números de licencia y cualquier otra preferencia que necesite cambiar.
  • Cargue su panel de control y cambie las preferencias de carga de archivos. Estos se almacenan en la base de datos y no se pueden poner en la configuración por alguna razón tonta.
  • Vuélvete loco.

Implemente un sitio en un nuevo servidor: 10 minutos

  • Borrar todos los cachés.
  • Exporte e importe la base de datos utilizando PHPMyAdmin o similar.
  • Encuentre la dirección IP y la información de la base de datos y agregue una nueva sección de caso de IP a config.php.
  • Confirma config.php en tu repositorio.
  • Consulte el repositorio de su sitio en la carpeta public_html de su nuevo servidor.
    • Si es un servidor local, use su cliente SVN.
    • Si es un servidor remoto, use el comando SSH svn checkout http://samplerepository.com/sampleproject/. El espacio y el punto después de la barra diagonal extrae el contenido de la carpeta a la carpeta actual; de lo contrario, obtendrá public_html/sampleproject/index.php si omite el punto.
  • Establezca las siguientes carpetas y sus contenidos en los permisos 777:
    • /plantillas
    • /uploads (o como se llame su carpeta de carga)
    • /system/expressionengine/cache/db_cache
  • Cargue su panel de control y cambie las preferencias de carga de archivos.

Actualizar un sitio a un servidor existente: de 1 a 5 minutos

  • Borre todas las cachés (solo si ha realizado cambios en la base de datos).
  • Exporte e importe la base de datos utilizando PHPMyAdmin o similar (solo si ha realizado cambios en la base de datos).
  • Ejecute una actualización SVN en la copia de su sitio:
    • Si es un servidor local, use su cliente SVN.
    • Si es un servidor remoto, use el comando SSH svn update. No debería necesitar volver a ingresar la URL o la contraseña.
  • Cargue su panel de control y cambie las preferencias de carga de archivos (solo si ha realizado cambios en la base de datos).

Conclusión - Estancia en el desierto DRY

A medida que avanza en el diseño y desarrollo de su sitio web ExpressionEngine, manténgase mentalmente consciente de lo que está haciendo en todo momento, desde una perspectiva general y funcional. Algunas piezas de la funcionalidad del sitio web son casi idénticas en todos los sitios, solo necesitan algunos ajustes menores de marcado y una "máscara" CSS para transferir fácilmente de uno a otro.

¡En el futuro, los microformatos estandarizarán aún más el marcado! Estos son candidatos ideales para su inclusión en su base de código. Uno que ya discutimos es el formulario de contacto ubicuo. Algunas otras funcionalidades "estándar" potenciales (he hecho que varios clientes soliciten estas cosas):

  • Blogs y sus formularios de comentarios asociados
  • Dirección o tarjetas v
  • Secciones de comunicados de prensa
  • Mapas de sitio XML o "Google"
  • Búsqueda y páginas de resultados de búsqueda
  • Personalizado ¡Comparta esto! código de tipo
  • Líneas de tiempo de Facebook o Twitter

Teóricamente, podría tener canales, categorías, grupos de campos personalizados y plantillas integradas y listas para funcionar (sé que lo hago para muchos de estos). Su cliente sigue obteniendo la misma cantidad de valor que obtendría si construyera a mano estas piezas para su sitio (posiblemente más, ya que serán refinadas y probadas con más frecuencia) y usted hace menos trabajo, lo que significa que puede pagar un precio más competitivo , o si vende una tarifa fija, cobre el mismo precio y obtenga más beneficios. ¡Recuerde divertirse y disfrutar desarrollando con ExpressionEngine!

Advertisement
Advertisement
Looking for something to help kick start your next project?
Envato Market has a range of items for sale to help get you started.