Pensez à l'avance à la mise à l'échelle, tirez le meilleur parti des solutions Wordpress standard, créez un thème WP de vos propres mains, prenez soin de la commodité d'un concepteur de mise en page, concentrez-vous sur la mobilité - et mettez à jour le blog de l'entreprise pour que les lecteurs, les éditeurs et les dirigeants l'adorent. Nous l'avons fait.
Le blog de Promopult a 9 ans. Pendant ce temps, il a traversé plusieurs transformations. Sergey Glazov , le technologue de notre blog et d'autres choses importantes dans le système Promopult, parle de ce dernier.
Ce n'est plus discuté, car c'est devenu la norme: un standard simple et rapide pour le blog d'une entreprise, une personne, un personnel, oui, peu importe, WordPress. Vous pouvez discuter, mais le fait demeure.
Je veux parler de ce que je suis venu en termes d'organisation du code, en travaillant avec le blog WordPress et son support. Cette histoire concerne le processus, car l'état actuel est le dernier point de ce processus et il semble que l'état actuel soit le plus réussi par rapport à toutes les itérations passées dans les approches de l'organisation.
Que s'est-il passé à (mon) début - en 2016
Il est rare qu'un développeur crée et réfléchisse à tout. Le plus souvent, il s'avère que déjà (le plus souvent même depuis longtemps, avec une histoire distincte ) il y a un projet qui doit être soutenu. Refonte, modifications, énormes savoirs traditionnels et exigences. Et dans les conditions de tout existant, il est nécessaire de naviguer rapidement et de résoudre les problèmes.
J'ai accepté le blog en 2016, alors qu'il avait déjà une longue histoire et que tout n'est pas aussi beau que je le voulais.
- Conception de blog ancienne avec une histoire de neuf ans.
- L'absence d'une version mobile / tablette sous quelque forme que ce soit.
- Plus de 600 messages.
- Problèmes structurels avec le contenu et son organisation: plus de 20 catégories et plus de neuf centaines de balises (maintenant plus, mais nous avons déjà arrêté).
- Les plans ont déjà changé de marque et se déplacent vers un nouveau domaine. Cela vaut également pour le blog.
- Une longue chaîne d'actions lorsque vous travaillez avec du code.
- Fonctionne sans contrôle de version (.git).
Premières tâches: mobilisation et conception
L'objectif principal était d'ajouter de l'adaptabilité au thème existant du blog: pour permettre aux utilisateurs mobiles de lire les articles et d'utiliser le site de manière adéquate - ils parlaient et écrivaient de plus en plus sur Mobile First , et les statistiques montraient qu'ils lisaient le blog à partir du mobile.
Parallèlement à ces travaux, un nouveau design a été dessiné.
En tant que développeur, j'ai travaillé en tandem avec le concepteur, sans chaîne de médiateurs inutile dans la discussion, donc le processus de communication a été plus rapide et plus animé. Le fait évident, bien sûr, mais pour une raison quelconque, il est négligé dans de nombreux processus. Et il s'avère que le designer fait quelque chose de très éloigné de la réalité. Parlez avec votre bouche et discutez de tous les points. Chaque participant au processus souhaite faire du bien et du cool. Mais tout le monde ne comprend pas que le processus est une chaîne connectée, et si un artiste individuel manque ou ne fait rien sur son site de travail, ce sera difficile pour les prochaines personnes dans le processus.
Au cours des travaux sur la version mobile, j'ai vu les inconvénients et les faiblesses de l'organisation du processus de développement. Je voulais accélérer et simplifier tout.
Comme nous l'avons fait avec le travail sur le code sur le blog
Il y avait une version DEV du blog avec une base de données de test séparée. Le travail avec les fichiers a eu lieu sur un serveur distant, les tests ont eu lieu à une adresse distincte, inaccessible au monde extérieur. Après le travail, les tests et la naissance d'une certaine unité de sens - elle a été déployée sur le blog de la bataille via un appel à l'administrateur. Ce qu'il a fait était une magie distincte.
Pour un blog où quelque chose change une fois par an, un excellent processus. Mais avec la nouvelle édition et ses besoins, un tel processus serait très pénible.
Ce que je voulais obtenir, comme on dit, "dans un monde idéal"
Tout le code réside. référentiels git . La version combat du blog est le master ce référentiel. Tout travail avec le code s'effectue via des dev vers une branche de développement ou d'autres branches associées à de grandes tâches individuelles.
Une fois la tâche terminée, une demande d'extraction (PR) et / ou une demande de fusion (MR) est créée avec un ensemble de modifications. La signification dans MR et PR est la même, mais dans des services différents - un nom différent. Nous avons GitLab , donc Merge Request.
Lors de la création de MR, une adresse temporaire de la forme -git--test.dev.blog.promopult.ru disponible, accessible uniquement par IP pour une vérification en direct sur l'environnement de test.
Le code dans le MR créé est revu et vérifié automatiquement (linter code, dont je vérifie la syntaxe selon des règles prédéfinies) et en mode manuel (la puissance verticale dans l'équipe, le timlid le regarde attentivement avec son œil attentif convexe naval). Après avoir passé l'examen - à partir de l'interface du navigateur du référentiel .git, le bouton "Fusionner" est enfoncé et toutes les modifications apparaissent sur l'air du blog de combat après une brève période de temps évidente.
Refonte, première approche
Plan de travail de refonte du blog:
- Mise en page d'un prototype statique pour les mises en page de conception de toutes les pages;
- Transformer ("étirer") la mise en page en thème WordPress.
Disposition - une étape distincte du travail. Pour un travail pratique avec les styles (CSS), le balisage et JS, le projet a utilisé un ensemble de plugins et de modules, qui est assemblé via les tâches Gulp décrites dans le générateur SPT (Start Project Template).
Les mots clés utilisés dans le collecteur du sujet de blog statique sont: HTML, CSS, JS, Babel, Gulp, PostCSS, SCSS, Nunjucks.
Une fois la mise en page terminée, la structure était la suivante ( seuls les répertoires de premier niveau sont indiqués ):
├── design # Design, mises en page et tout
├── app / # Sources de projet: modules séparés
├── dist / # La version assemblée du projet (fichiers html) et toutes les statiques
├── gulpfile.js / # Config Gulp.js
└── package.json # Fichier de configuration du collecteur: packages, scripts
Chaque élément sémantique visuel individuel sur la page, par exemple, une carte postale ( /components/article_card/ ), était un dossier dans lequel il se trouvait:
- fichier de balisage ( article_card.html ),
- fichier de styles ( article_card.scss ),
- Fichier JS ( article_card.js ).
Et chaque page a été assemblée à partir de ces blocs de composants séparés. Les blocs sont pratiques à manipuler et les modifications n'affectent pas les éléments voisins.
À la sortie, le collecteur a créé le dossier dist , qui contenait des fichiers html prêts à l'emploi de pages à visualiser dans le navigateur au stade de l'édition et de la coordination, ainsi qu'un fichier de style, tous les thèmes et deux fichiers JS: un fichier ( app.js ) décrivait la logique et le comportement site, le second ( vendor.js ) contenait toutes les bibliothèques utilisées pour le site (jQuery, fotorama, magnific-popup et autres).
Ensuite, vous devez transformer tout cela en un thème WordPress et réfléchir à la structure du fichier. Afin que vous puissiez facilement travailler avec une mise en page statique, et à côté de lui, un thème WP.
Liste des mises en page préparées par le concepteur. Ils sont identiques aux fichiers de thème du blog WordPress:
- Page d'accueil (fichier
home.php ). single.php / page de publication ( single.php ).- Vue d'une seule page de texte (
page.php ). - La page d'abonnement à la newsletter (
subscribe.php ). - Erreur 404 (
404.php ). - Page de balise séparée (
tag.php ). - Page de catégorie distincte (
category.php ). - Recherche et résultats de recherche (
search.php ).
Un flux de travail avec cette approche et la séparation de la version statique et de la version WordPress du thème est le suivant: si vous devez corriger quelque chose dans la partie visuelle - les modifications sont apportées dans la version statique et après le test sont transférées vers le thème. Si des modifications sont nécessaires dans une partie non visuelle, seuls les fichiers de thème WP sont modifiés.
Le dossier du thème du blog est bsp . Il est situé le long du chemin d'accès dans le dossier avec les sujets du blog lui-même:
├── wp-content / # Fichiers de site WordPress personnalisés
│ ├── thèmes / # Thèmes du site
│ │ ├── app / # Sources d'un thème statique
│ │ │ ├── gulpfile.js / # Tâches Gulp pour l'assemblage
│ │ ├── dist / # Créer un sujet statique
│ │ │ ├── actifs / # Ressources: JS, CSS et graphiques
│ │ ├── Thème du blog bsp / # WP-PromoPult
│ │ │ ├── actifs / # Ressources: JS, CSS et graphiques, copie depuis `/ dist /`
│ │ │ ├── home.php # La page principale du blog et d'autres fichiers à la racine du sujet
La place du thème wordpress est évidente et prédéterminée par la structure des fichiers de WordPress lui-même.
Il n'y a pas d'autres sujets dans le répertoire des thèmes - tout le standard a été supprimé. Il existe un mythe sur l'augmentation de la productivité de cette manière, mais nous ne l'avons pas remarqué. Cela se fait plus pour l'ordre dans le code. Pas besoin de stocker ce qui n'est pas utilisé et ne sera certainement pas utilisé.
Tous les plugins WP utilisés sont également en .git. Sur notre site, ce sont les plans de site XML XML, RSS pour Yandex Turbo, RusToLat et WP-PostViews.
Le prototype statique et compilé des pages de blog et des fichiers source a été déplacé vers le répertoire des thèmes du blog: afin d'interagir de manière pratique avec la partie logique du modèle et avec tout ce qui est responsable de l'apparence et du comportement des éléments sur la page.
Une version statique de l'assembly du projet - avec la source et toutes les dépendances lors de la première tentative d'organisation de la structure - a été placée dans le répertoire des thèmes.
Autrement dit, à côté du thème bsp principal, le répertoire /app été ajouté, dans lequel se trouvent le code source de la disposition du thème et le gulp-collector. Mais dans cette version, il y a eu un moment difficile: les fichiers statiques ont été générés dans un répertoire séparé, et pour que les modifications soient dans le thème WP, il était nécessaire de copier les fichiers de style statique et les scripts dans le dossier d' assets à l'intérieur du thème.
Deuxième approche: une nouvelle version de la structure
Au cours des premières semaines, cela a été décidé par un simple script de console qui copiait les fichiers collectés d'un thème statique vers un thème WP. Une action excessive entraîne des erreurs. Par conséquent, l'option consistait uniquement à corriger la structure.
Nous avons trois répertoires importants (depuis la racine):
- Thème WP:
/wp-content/themes/bsp - Sources d'un thème statique:
/app - Sujet statique collecté:
/dist
Et à l'intérieur, il y a des assets avec des fichiers de styles, des graphiques et JS
Vous devez tout organiser pour que les fichiers de styles et de scripts statiques soient collectés dans le dossier souhaité ( /wp-content/themes/bsp/assets ).
La nouvelle version de la structure était la suivante:
├── gulpfile.js / # Tâches Gulp pour l'assemblage
├── wp-content / # Fichiers de site WordPress personnalisés
│ ├── plugins / # WP-plugins
│ ├── thèmes / # Thèmes du site
│ │ ├── bsp / # PromoPult Rubrique du blog
│ │ │ ├── app / # Sources d'un sujet statique
│ │ │ ├── actifs / # Ressources: JS, CSS et graphiques (génération automatique)
│ │ │ ├── home.php # La page principale du blog et d'autres fichiers à la racine du sujet
├── fichiers wp-admin / # WP pour le panneau d'administration
├── wp-includes / # WP-files du système
À la racine de l'ensemble du projet se trouvent des tâches de gulp - et sont exécutées à partir de la racine. La configuration de gulp-task décrit la structure selon laquelle les fichiers statiques sont collectés du répertoire wp-content/themes/bsp/app vers wp-content/themes/bsp/assets sans aucune action supplémentaire telle que la copie, etc.
Les fichiers de thème WP restent inchangés et le travail se déroule selon l'ancien scénario: modifications en statique → transfert vers les fichiers WP. Les statiques CSS et JS sont générées immédiatement dans le dossier du thème et tout fonctionne.
Tout cela concernait le processus de travail. Maintenant, comment le blog est organisé.
Blog PromoPult: Comment ça marche
La principale force du blog est l'équipe. Éditeur, auteurs, concepteurs de mise en page.
La grande tâche consiste à rendre le travail avec le contenu du blog pratique dans la zone d'administration. Et compte tenu du fait que le thème de notre blog a été créé spécifiquement pour les tâches de contenu et les demandes éditoriales, le panneau d'administration a été modifié en conséquence.
Liste de contrôle avant publication
Tout travail est important à contrôler. La mise en page de l'article est un processus standardisé et formalisé, qui peut être facilement présenté sous la forme d'une liste de contrôle.
Les gars ont vu l'idée d'EmailSoldiers . Nous avons décidé de l'appliquer à la maison.
Si aucun élément n'est coché, le système vous avertira avant la publication.
En cliquant sur les liens, les liens soulignés dans l'élément de liste - sélectionnez un élément spécifique.
La liste de contrôle est compilée dans le même ordre que les paramètres de publication supplémentaires dans le panneau d'administration.
Paramètres des articles de blog
Étroitement lié à la liste de contrôle des publications décrite ci-dessus.
Lors du développement du sujet, j'ai essayé de ne pas utiliser de plugins, mais de faire une solution simple et facile pour les tâches du sujet. Faits saillants:
- Descriptions des balises META SEO.
- Descriptions des balises OpenGraph qui utilisent les réseaux sociaux pour partager du matériel et former de jolies fiches d'articles.
- Travail pratique avec des images de couverture pour les messages. Une image est requise - elle est ajoutée à la carte postale dans la vignette de publication, qui est affichée sur la page principale et sur la page d'en-tête ou de balise.
- Paramètres de thème supplémentaires: une publication peut être avec ou sans couverture, il y a un court texte d'annonce que nous affichons dans l'en-tête avec une couverture, et il est également utilisé dans la description de l'article dans la liste de diffusion Digest.
La section des paramètres de publication est implémentée via des méta-boîtes et des champs personnalisés dans WordPress.
Grâce à la méta-boîte, la liste de contrôle de publication a également été ajoutée.
Dans les modèles, travailler avec des champs est simple: si le champ n'est pas vide et rempli, nous obtenons la valeur et la montrons. Par exemple, voici comment la réaction de blocage au message est affichée:
<?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 exemple de sortie de réaction sur une carte postale:
De jolies petites choses
Il y a de belles petites choses que peut-être personne ne voit. Mais si quelqu'un a remarqué - bien.
Par exemple, les dates de publication d'un poste sur cartes et dans un poste séparé dans notre alphabet cyrillique et savoir s'incliner. Pour une raison quelconque, ce n'est pas dans la boîte WordPress. Si la date de publication est dans l'année en cours, l'année ne s'affiche pas avec nous, si l'année diffère de l'année en cours, la date est affichée avec l'année de publication.
Compteur de commentaires. Ils ont longtemps soutenu que «0 commentaire» ou «aucun commentaire» est très déroutant. La solution est très simple: ne pas afficher du tout le compteur de commentaires s'il y a moins d'un commentaire.
En général, nous travaillons séparément sur un système de commentaires et aimerions en parler dans un grand post séparé. Nous créons un système de commentaires simple et pratique avec une simple autorisation via les réseaux sociaux.
Propres goûts: commenter ou partager des liens dans les réseaux sociaux est une longue affaire par le taux de consommation de contenu, mais cliquez sur «J'aime» et dites clairement que l'article est cool - simple et rapide. Nous avons fait nos goûts simples et mis le compteur sur la carte postale. Et les goûts arrivent assez rapidement. Et comme ils sont en bas de l'article, c'est aussi un signal que le texte a été lu.
Ils ont créé un thème sombre pour leur blog - maintenant c'est à la mode. Compte tenu de la structure modulaire (en fait, le site est un ensemble de blocs qui sont en quelque sorte combinés entre eux) et de l'organisation des styles, cela s'est avéré assez rapide.
A propos d'une technique intéressante
Il y a une minification du code de balisage, CSS et JS dans le sujet. CSS et JS sont compressés via des tâches de gulp dans le collecteur de statiques, mais la minification du balisage se fait via le hook WordPress WP_HTML_Compression .
Et dans les commentaires dans le balisage, nous avons ajouté un code promotionnel pour ceux qui sont intéressés par la façon dont le site est organisé de l'intérieur et qui vont d'abord regarder le code source:
Mise en cache CSS et JS. Pour mettre en cache les styles et les fichiers de script, mais toujours pertinents, si nous refaisons quelque chose, nous utilisons filemtime (). Beaucoup dans ce cas utilisent ?<?php echo time(); ?> ?<?php echo time(); ?> . Mais cette option télécharge le fichier et fait une demande à chaque appel.
Mieux vaut utiliser une telle astuce:
<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'); ?>" />
Dans ce cas, les fichiers seront téléchargés s'ils ont été modifiés et la date de modification du fichier sera ajoutée au paramètre de demande.
Quels plugins nous utilisons
Malgré la possibilité et le désir dans certains cas de s'en sortir avec votre décision, nous utilisons toujours des plugins. Notre liste est la suivante:
Conseils de conclusion pour ceux qui travaillent sur le blog d'une entreprise
- Je vous conseille au début des travaux sur le projet de penser immédiatement à la mise à l'échelle.
- Assurez-vous d'utiliser
.git dans votre travail. Pour 2019, bien sûr, des conseils étranges, mais ces conseils peuvent sauver quelqu'un des cheveux gris et réprimander en cas de problème. - Il est préférable de diviser le développement et de travailler sur un thème WordPress en deux étapes: d'abord, créer quelque chose de statique, et déjà fait «tirer» quelque chose comme un thème WordPress.
- S'il y a une opportunité - temps, équipe et compréhension des raisons pour lesquelles vous avez besoin de tout cela - faites-le vous-même, sans utiliser d'options prêtes à l'emploi. Gagner dans l'ordre et comprendre comment tout fonctionne. Vous ne produirez pas de béquilles.
- Utilisez des crochets et des fonctionnalités WordPress standard si votre blog est construit dessus. La personnalisation et la création d'une solution pratique sont rapides et faciles.
- Rendez-le pratique pour l'utilisateur et les éditeurs.
- N'oubliez pas les réseaux sociaux et la micro-mise en page.
- N'oubliez pas les versions mobiles.
- N'oubliez pas les mises à jour régulières des plugins et des systèmes.
- Sélectionnez uniquement des plugins éprouvés.
Le travail sur le blog continue - restez avec nous.