Piense de antemano en la ampliación, maximice el uso de las soluciones estándar de Wordpress, cree un tema WP con sus propias manos, cuide la conveniencia de un diseñador de diseño, concéntrese en la movilidad y actualice el blog de la compañía para que a los lectores, editores y ejecutivos les encante. Lo hicimos
El blog de Promopult tiene 9 años. Durante este tiempo pasó por varias transformaciones. Sergey Glazov , el tecnólogo de nuestro blog y otras cosas importantes en el sistema Promopult, habla sobre esto último.
Esto ya no se discute, porque se ha convertido en la norma: un estándar rápido y simple para el blog de una empresa, una persona, un personal, sí, lo que sea, WordPress. Puedes discutir, pero el hecho permanece.
Quiero hablar sobre lo que encontré en términos de organización del código, trabajando con el blog de WordPress y su soporte. Esta historia trata sobre el proceso, porque el estado actual es el último punto en este proceso y parece que el estado actual es el más exitoso en comparación con todas las iteraciones pasadas en los enfoques de la organización.
Lo que sucedió en (mi) inicio - en 2016
Es raro que un desarrollador cree y piense en todo desde cero. Más a menudo, resulta que ya (a menudo incluso hace mucho tiempo, con un historial separado ) hay un proyecto que necesita ser apoyado. Rediseño, ediciones, enormes conocimientos tradicionales y requisitos. Y en las condiciones del todo existente, es necesario navegar de alguna manera rápidamente y resolver problemas.
Acepté el blog en 2016, cuando ya tenía una larga historia y no todo es tan hermoso como quería.
- Diseño de blog antiguo con una historia de nueve años.
- La falta de una versión móvil / tableta en cualquier forma.
- Más de 600 publicaciones.
- Problemas estructurales con el contenido y su organización: más de 20 categorías y más de nueve cientos de etiquetas (ahora más, pero ya nos hemos detenido).
- Los planes ya tienen cambio de marca y cambio a un nuevo dominio. Esto también se aplica al blog.
- Una larga cadena de acciones cuando se trabaja con código.
- Trabajar sin control de versiones (.git).
Primeras tareas: movilización y diseño.
La tarea principal era agregar adaptabilidad al tema existente del blog: hacer que los usuarios de dispositivos móviles puedan leer publicaciones y usar el sitio adecuadamente; hablaron y escribieron sobre Mobile First cada vez más, y las estadísticas mostraron que leyeron el blog desde dispositivos móviles.
Paralelamente a estas obras, se dibujó un nuevo diseño.
Como desarrollador, fui emparejado con un diseñador, sin una cadena innecesaria de mediadores en la discusión, por lo que el proceso de comunicación fue más rápido y más animado. El hecho obvio, por supuesto, pero por alguna razón se descuida en muchos procesos. Y resulta que el diseñador está haciendo algo muy divorciado de la realidad. Hable con su boca y discuta todos los puntos. Cada participante en el proceso está interesado en hacer el bien y la calma. Pero no todos entienden que el proceso es una cadena conectada, y si un artista individual falla o no hace algo en su área de trabajo, será difícil para las siguientes personas en el proceso.
En el curso del trabajo en la versión móvil, vi los inconvenientes y las debilidades de la organización del proceso de desarrollo. Quería acelerar y simplificar todo.
Como lo hicimos con el trabajo sobre el código en el blog
Había una versión DEV del blog con una base de datos de prueba separada. El trabajo con archivos se realizó en un servidor remoto, las pruebas se realizaron en una dirección separada, inaccesible en el mundo exterior. Después del trabajo, las pruebas y el nacimiento de una cierta unidad de significado, se lanzó al blog de batalla a través de una apelación al administrador. Lo que hizo fue una magia separada.
Para un blog donde algo cambia una vez al año, un gran proceso. Pero con la nueva edición y sus necesidades, tal proceso sería un gran dolor.
Lo que quería obtener, como dicen, "en un mundo ideal"
Todo el código está en. repositorios git . La versión de combate del blog es el master este repositorio. Todo el trabajo con el código ocurre a través de confirmaciones a una rama de desarrollo u otras ramas asociadas con tareas grandes individuales.
Una vez realizada la tarea, se crea una solicitud de extracción (PR) y / o una solicitud de fusión (MR) con un conjunto de ediciones. El significado en MR y PR es el mismo, pero en diferentes servicios, un nombre diferente. Tenemos GitLab , así que Solicitud de fusión.
Al crear MR, una dirección temporal del formulario -git--test.dev.blog.promopult.ru disponible, accesible solo por IP para verificación en vivo en el entorno de prueba.
El código en el MR creado se revisa y verifica automáticamente (código linter, que verifico la sintaxis de acuerdo con las reglas predefinidas) y en modo manual (la potencia vertical en el equipo, el tímido lo mira cuidadosamente con su ojo atento convexo naval). Después de pasar la revisión, desde la interfaz del navegador del repositorio .git, se hace clic en el botón Combinar y todos los cambios aparecen en el aire del blog de combate después de un breve período de tiempo obvio.
Rediseño, primer acercamiento
Plan de trabajo de rediseño de blog:
- Diseño de un prototipo estático para los diseños de diseño de todas las páginas;
- Convertir el diseño ("estiramiento") en un tema de WordPress.
Diseño: una etapa separada del trabajo. Para un trabajo conveniente con estilos (CSS), marcado y JS, se utilizó un conjunto de complementos y módulos en el proyecto, que se ensambla a través de las tareas Gulp descritas en el constructor SPT (Iniciar plantilla de proyecto).
Las palabras clave que se usan en el recopilador de un tema de blog estático son: HTML, CSS, JS, Babel, Gulp, PostCSS, SCSS, Nunjucks.
Al completar el diseño, la estructura era la siguiente ( solo se indican los directorios de primer nivel ):
├── diseño # Diseño, diseños y todo
├── aplicación / # Fuentes del proyecto: módulos separados
├── dist / # La versión ensamblada del proyecto (archivos html) y todas las estadísticas
├── gulpfile.js / # Config Gulp.js
└── package.json # Archivo de configuración del recopilador: paquetes, scripts
Cada elemento semántico visual individual en la página, por ejemplo, una tarjeta postal ( /components/article_card/ ), era una carpeta en la que estaba:
- archivo de marcado ( article_card.html ),
- archivo de estilos ( article_card.scss ),
- Archivo JS ( article_card.js ).
Y cada página se ensambló a partir de bloques de componentes separados. Los bloques son convenientes de manipular, y cualquier cambio no afecta a los elementos vecinos.
En la salida, el recopilador creó la carpeta dist , que contenía archivos html de páginas listos para su visualización en el navegador en la etapa de edición y coordinación, así como un archivo de estilo, todos los temas y dos archivos JS: un archivo ( app.js ) describe la lógica y el comportamiento sitio, el segundo ( vendor.js ) contenía todas las bibliotecas utilizadas para el sitio (jQuery, fotorama, magnific-popup y otros).
A continuación, debe convertir todo esto en un tema de WordPress y pensar en la estructura del archivo. Para que pueda trabajar convenientemente con un diseño estático, y al lado, coloque un tema WP.
Lista de diseños preparados por el diseñador. Son los mismos que los archivos de tema de blog de WordPress:
- Página de inicio (archivo
home.php ). single.php / página de publicación ( single.php ).- Vista de una sola página de texto (
page.php ). - La página de suscripción al boletín (
subscribe.php ). - Error 404 (
404.php ). - Página de etiqueta separada (
tag.php ). - Página de categoría separada (
category.php ). - Búsqueda y resultados de búsqueda (
search.php ).
Un flujo de trabajo con este enfoque y la separación de la versión estática y la versión de WordPress del tema es el siguiente: si necesita arreglar algo en la parte visual, los cambios se realizan en la versión estática y después de que la prueba se transfiere al tema. Si se necesitan ediciones en alguna parte no visual, entonces solo se cambian los archivos de tema WP.
La carpeta del tema del blog es bsp . Se encuentra a lo largo de la ruta en la carpeta con los temas del blog en sí:
├── wp-content / # Archivos personalizados del sitio de WordPress
│ ├── temas / # temas del sitio
│ │ ├── aplicación / # Fuentes de un tema estático
│ │ │ ├── gulpfile.js / # Gulp-tareas para ensamblar
│ │ ├── dist / # Crear un tema estático
│ │ │ ├── activos / # Recursos: JS, CSS y gráficos
│ │ ├── bsp / # WP-PromoPult Blog Theme
│ │ │ ├── assets / # Resources: JS, CSS y gráficos, copiando desde `/ dist /`
│ │ │ ├── home.php # La página principal del blog y otros archivos en la raíz del tema
El lugar del tema de WordPress es obvio y está predeterminado por la estructura de archivos de WordPress.
No hay otros temas en el directorio de temas: todo lo estándar se ha eliminado. Existe un mito sobre el aumento de la productividad de esta manera, pero no nos dimos cuenta de esto. Esto se hace más por orden en el código. No es necesario almacenar lo que no se usa y definitivamente no se usará.
También en .git están todos los complementos de WP que se usan. En nuestro sitio, estos son Google XML Sitemaps, RSS para Yandex Turbo, RusToLat y WP-PostViews.
El prototipo estático y compilado de las páginas del blog y los archivos fuente se movieron al directorio de temas del blog: para interactuar convenientemente con la parte lógica de la plantilla y con todo lo que es responsable de la apariencia y el comportamiento de los elementos en la página.
Se colocó en el directorio de temas una versión estática del ensamblaje del proyecto, con la fuente y todas las dependencias en el primer intento de organizar la estructura.
Es decir, junto al tema principal de bsp , se agregó el directorio /app , en el que se encuentra el código fuente para el diseño del tema y el gulp-collector. Pero en esta versión hubo un momento difícil: los archivos estáticos se generaron en un directorio separado, y para que los cambios estuvieran en el tema WP, fue necesario copiar los archivos de estilo estático y las secuencias de comandos en la carpeta de assets dentro del tema.
Segundo enfoque: una nueva versión de la estructura.
En las primeras semanas, esto se decidió mediante un simple script de consola que copió los archivos recopilados de un tema estático a un tema de WP. La acción excesiva conduce a errores. Por lo tanto, la opción era solo corregir la estructura.
Tenemos tres directorios importantes (desde la raíz):
- Tema de WP:
/wp-content/themes/bsp - Fuentes de un tema estático:
/app - Tema estático recopilado:
/dist
Y dentro de él hay assets con archivos de estilos, gráficos y JS
Debe organizar todo para que los archivos de estilos estáticos y scripts se recopilen en la carpeta deseada ( /wp-content/themes/bsp/assets ).
La nueva versión de la estructura fue la siguiente:
├── gulpfile.js / # Gulp-tareas para ensamblar
├── wp-content / # Archivos personalizados del sitio de WordPress
│ ├── complementos / # complementos WP
│ ├── temas / # temas del sitio
│ │ ├── bsp / # Tema del blog de PromoPult
│ │ │ ├── app / # Fuentes de un tema estático
│ │ │ ├── activos / # Recursos: JS, CSS y gráficos (generación automática)
│ │ │ ├── home.php # La página principal del blog y otros archivos en la raíz del tema
├── wp-admin / # WP-files para el panel de administración
├── wp-includes / # WP-files del sistema
En la raíz de todo el proyecto hay tareas de trago, y se ejecutan desde la raíz. La configuración de gulp-task describe la estructura en la que los archivos estáticos se recopilan del directorio wp-content/themes/bsp/app a wp-content/themes/bsp/assets sin ninguna acción adicional como copiar, etc.
Los archivos de tema WP permanecen sin cambios y el trabajo continúa de acuerdo con el escenario anterior: ediciones en estática → transferencia a archivos WP. Las estadísticas CSS y JS se generan inmediatamente en la carpeta de temas y todo funciona.
Todo esto fue sobre el proceso de trabajo. Ahora sobre cómo está organizado el blog.
Blog PromoPult: cómo funciona
El poder principal del blog es el equipo. Editor, autores, diseñadores de maquetación.
La gran tarea es hacer que trabajar con el contenido del blog sea conveniente en el área de administración. Y teniendo en cuenta el hecho de que el tema de nuestro blog se creó específicamente para tareas de contenido y solicitudes editoriales, el panel de administración se modificó en consecuencia.
Lista de verificación antes de la publicación
Cualquier trabajo es importante para controlar. El diseño del artículo es un proceso estándar y formalizado, que se puede presentar fácilmente en forma de una lista de verificación.
Los chicos vieron la idea de EmailSoldiers . Decidimos aplicarlo en casa.
Si algún elemento no está marcado, el sistema le avisará antes de la publicación.
Al hacer clic en los enlaces, enlaces subrayados en el elemento de la lista, resalte un elemento específico.
La lista de verificación se compila en el mismo orden que la configuración de publicación adicional en el panel de administración.
Configuración de publicación de blog
Estrechamente entretejido con la lista de verificación de publicación descrita anteriormente.
Al desarrollar el tema, traté de no usar complementos, sino de hacer una solución simple y fácil para las tareas del tema. Destacados:
- Descripciones para metaetiquetas SEO.
- Descripciones de etiquetas OpenGraph que usan redes sociales para compartir material y formar bonitas tarjetas de artículos.
- Trabajo conveniente con imágenes de portada para publicaciones. Se requiere una imagen: se agrega a la tarjeta postal en el mosaico de publicación, que se muestra en la página principal y en la página de encabezado o etiqueta.
- Configuraciones de tema adicionales: una publicación puede ser con o sin una portada, hay un breve texto de anuncio que mostramos en el encabezado con una portada, y también se usa en la descripción del artículo en la lista de correo de resumen.
La sección de configuración de publicaciones se implementa a través de metacajas y campos personalizados en WordPress.
A través de la casilla meta, también se ha agregado la lista de verificación de publicación.
En las plantillas, trabajar con campos es simple: si el campo no está vacío y lleno, obtenemos el valor y lo mostramos. Por ejemplo, así es como se muestra la reacción de bloqueo a la publicación:
<?php if (get_post_meta($post->ID, 'postreaction', true)) { ?> <div class="article_reaction"> <div class="label-reaction"><span><?php echo get_post_meta($post->ID, 'postreaction', true); ?></span></div> </div><!-- /.article_reaction --> <?php } ?>
Un ejemplo de una salida de reacción en una tarjeta postal:
Pequeñas cosas bonitas
Hay algunas pequeñas cosas agradables que tal vez nadie ve. Pero si alguien se dio cuenta, bien.
Por ejemplo, las fechas de publicación de una publicación en tarjetas y en una publicación separada en nuestro alfabeto cirílico y saber cómo inclinarse. Por alguna razón, esto no está en el cuadro de WordPress. Si la fecha de publicación es el año actual, entonces el año no se muestra con nosotros, si el año difiere del actual, la fecha se muestra junto con el año de publicación.
Publicar contador de comentarios. Argumentaron durante mucho tiempo que "0 comentarios" o "sin comentarios" es muy confuso. La solución es muy simple: no muestre el contador de comentarios si hay menos de un comentario.
En general, estamos trabajando en un sistema de comentarios por separado y nos gustaría hablar sobre ello en una gran publicación separada. Hacemos un sistema de comentarios simple y conveniente con autorización simple a través de las redes sociales.
Me gusta: comentar o compartir enlaces en las redes sociales es una cuestión larga por la tasa de consumo de contenido, pero haga clic en "me gusta" y deje en claro que el artículo es genial, simple y rápido. Hicimos nuestros gustos simples y colocamos el mostrador en la tarjeta postal. Y los gustos llegan bastante rápido. Y dado que están al final del artículo, también es una señal de que el texto ha sido leído.
Hicieron un tema oscuro para su blog, ahora está de moda. Dada la estructura modular (de hecho, el sitio es un conjunto de bloques que de alguna manera se combinan entre sí) y la organización de los estilos, resultó que se hizo con bastante rapidez.
Sobre una técnica interesante
Hay minificación de código de marcado, CSS y JS en el tema. CSS y JS se comprimen mediante tareas de trago en el recopilador de estadísticas, pero la minificación del marcado se realiza a través del WP_HTML_Compression WordPress.
Y en el comentario en el marcado, agregamos un código promocional para aquellos que están interesados en cómo se organiza el sitio desde adentro y que primero van a ver el código fuente:
Almacenamiento en caché CSS y JS. Para almacenar en caché los estilos y los archivos de script, pero siempre ser relevantes, si rehacemos algo, usamos filemtime (). Muchos en este caso usan ?<?php echo time(); ?> ?<?php echo time(); ?> . Pero esta opción descarga el archivo y realiza una solicitud con cada llamada.
Es mejor usar un truco así:
<link rel="stylesheet" type="text/css" href="<?php echo get_template_directory_uri(); ?>/assets/styles/style.css?t=<?php echo filemtime(get_theme_file_path().'/assets/styles/style.css'); ?>" />
En este caso, los archivos se descargarán si se han cambiado, y la fecha en que se modificó el archivo se agregará al parámetro de solicitud.
Qué complementos usamos
A pesar de la posibilidad y el deseo en algunos casos de salir adelante con su decisión, todavía utilizamos complementos. Nuestra lista es la siguiente:
Consejos de conclusión para quienes trabajan en el blog de una empresa
- Al comienzo del trabajo en el proyecto, le aconsejo que piense inmediatamente en la ampliación.
- Asegúrese de usar
.git en su trabajo. Para 2019, por supuesto, consejos extraños, pero este consejo puede salvar a alguien de las canas y reprender cuando algo sale mal. - Es mejor dividir el desarrollo y trabajar en un tema de WordPress en dos etapas: primero, inventar algo estático, y ya hecho "extraer" algo como un tema de WordPress.
- Si hay una oportunidad, tiempo, equipo y comprensión de por qué necesita todo esto, hágalo usted mismo, sin usar opciones ya preparadas. Gana en orden y entendiendo cómo funciona todo. No producirás muletas.
- Use los ganchos y funciones estándar de WordPress si su blog está construido sobre él. Personalizar y hacer una solución conveniente es rápido y fácil.
- Que sea conveniente para el usuario y los editores.
- No te olvides de las redes sociales y el micro diseño.
- No te olvides de las versiones móviles.
- No te olvides de las actualizaciones periódicas de complementos y sistemas.
- Solo seleccione complementos probados.
El trabajo en el blog continúa, quédate con nosotros.