How to organize the development and support of a blog on WordPress in 2Q19 and not to fix

Think ahead of time about scaling, maximize the use of standard Wordpress solutions, do a WP theme yourself, take care of the layout maker's convenience, push up on mobility - and update the company's blog so that readers, editors and managers love it. We made it.

The Promopult company blog is already 9 years old. During this time, he went through several transformations. Sergey Glazov , the technologist of our blog and other important pieces in the Promopult system, talks about the latter.

This is no longer discussed, because it has become the norm: a fast and simple standard for a company's blog, person, personal, and in general, of any kind - WordPress. It is possible to argue, but the fact remains.

I want to talk about what I came up with in terms of organizing code, working with a WordPress blog and its support. This story is about the process, because the current state is the last point in this process and it seems that the current state is the most successful compared to all past iterations in the approaches to the organization.

What was on (my) start - in 2016

Rarely when a developer creates and thinks everything from scratch. More often it turns out that already ( more often, even for a long time, with a separate story ) there is a project that needs to be supported. Redesign, edits, huge TK and requirements. And in the conditions of existing things, you need to somehow quickly navigate and solve problems.

I accepted the blog in 2016, when it already had a long history and not everything is as good as it should be.

1. Old blog design with a nine-year history.
2. The absence of a mobile / tablet version in any form.
3. More than 600 posts.
4. Structural problems with content and its organization: 20+ categories and more than nine hundred tags (now more, but we have already stopped).
5. The plans already have a rebranding and moving to a new domain. The blog is also concerned.
6. Long chain of actions when working with code.
7. Work without version control (.git).

First tasks: mobilization and design

The primary task was to add adaptability to the existing blog topic: to make mobile users adequately read posts and use the site — Mobile First was talked about and written more and more, and statistics showed that the blog was read from mobile.

In parallel with these works, a new design was drawn.

I, as a developer, worked in tandem with a designer, without a lot of intermediaries in the discussion, so the communication process was faster and more lively. The obvious fact, of course, but for some reason in many processes it is neglected. And it turns out that the designer is doing something badly out of touch with reality. Talk with your mouth and discuss all the points. Every participant in the process is interested in doing well and cool. But not everyone understands that the process is a connected chain, and if an individual contractor at his site of work misses something or does not do it - it will be difficult for the next people in the process.

In the course of working on the mobile version, I saw the disadvantages and weaknesses of the organization of the development process. I wanted to speed up and simplify everything.

As we had with the work on the code in the blog

There was a DEV-version of the blog with a separate test database. Work with files took place on a remote server, testing took place at a separate address that was not available in the outside world. After work, testing and the birth of some unit of meaning - she rolled out to the combat blog through an appeal to the admin. What he did was separate magic.

For a blog where something changes once a year is a great process. But with the new edition and its needs such a process would be a big pain.

What I wanted to get, as they say, "in an ideal world"

All code lies in. git repositories. The combat version of the blog is the master branch of this repository. All work with the code occurs through commits to the dev file or other branches associated with individual large tasks.

After the task is done, a Pull Request (PR) and / or Merge Request (MR) is created with a set of edits. The meaning of MR b PR is the same, but in different services - a different name. We have GitLab , therefore - Merge Request.

When creating MR, a temporary address of the form -git--test.dev.blog.promopult.ru available, which is available only by IP for live testing on a test environment.

The code in the created MR is reviewed and checked automatically (code linters, which check the syntax according to predefined rules) and manually (the vertical of power in the team, stares at everything with its naval bulging attentive eye of the tmilid). After the review is completed, the “Merge” button is pressed from the browser's .git-repository interface and all changes appear on the air of the combat blog after a brief, obvious period of time.

Redesign, first approach

Work plan for blog redesign:

1. Layout static prototype on the design of all pages;
2. The transformation ("stretch") of the layout in the WordPress-theme.

Layout - a separate stage of work. For convenient work with styles (CSS), markup and JS, a set of plug-ins and modules was used in the project, which is assembled through the Gulp tasks described in the Start Project Template ( SPT ) collector.

Keywords that are used in the static blog theme collector: HTML, CSS, JS, Babel, Gulp, PostCSS, SCSS, Nunjucks.

Upon completion of the layout, the structure was as follows ( only the first level directories are indicated ):

  ├── design # Design, layouts and all
 App── app / # project sources: individual modules
 Dist── dist / # Compiled version of the project (html-files) and all the statics
 Ulp── gulpfile.js / # Gulp.js config
 Package── package.json # File-builder config: packages, scripts 

Each individual visual semantic element on the page, for example, a post card ( /components/article_card/ ), was a folder in which it was:

- markup file ( article_card.html ),

- style file ( article_card.scss ),

- JS file ( article_card.js ).

And each page was assembled from such separate component blocks. It is convenient to manipulate blocks, and any changes do not affect neighboring elements.

At the output, the collector created the dist folder, which contained ready-made html-files of pages for visual viewing in the browser at the editing and approval stage, as well as one style sheet all themes and two JS files: one file ( app.js ) described the logic and behavior site, the second ( vendor.js ) contained all the libraries used for the site (jQuery, fotorama, magnific-popup and others).

Then all this needs to be turned into a WordPress theme and think through the file structure. So that you can conveniently work with a static layout and next to it lay a WP-theme.

The list of layouts that the designer has prepared. They are the same as the WordPress files of the blog:

• Home page ( home.php file).
• single.php post / post page ( single.php ).
• View a separate text page ( page.php ).
• Subscribe subscription page ( subscribe.php ).
• Error 404 ( 404.php ).
• Separate tag page ( tag.php ).
• Separate category page ( category.php ).
• Search and search results ( search.php ).

A workflow with this approach and separation into a static version and a WordPress version of a theme occurs as follows: if you need to correct something in the visual part, the edits are made in a static version and transferred to the theme after the test. If edits are needed in some non-visual part, then only WP-theme files are changed.

The folder with the blog theme is bsp . It is located on the way in a folder with the themes of the blog itself:

  W── wp-content / # Custom WordPress site files
 │ ├── themes / # Site Themes
 │ │ ├── app / # Sources for a static theme
 │ │ │ ├── gulpfile.js / # Gulp-tasks for assembly
 │ │ ├── dist / # Build a static theme
 │ │ │ ├── assets / # Resources: JS, CSS and graphics 
 │ │ ├── bsp / # WP-Theme Blog PromoPult
 │ │ │ ├── assets / # Resources: JS, CSS and graphics, copying from `/ dist /`
 │ │ │ ├── home.php #Blog home page and other files in the root of the topic 

The place of the wordpress theme is obvious and predetermined by the file structure of WordPress itself.

There are no other topics in the themes directory - everything standard has been deleted. There is a myth about improving performance in this way, but we did not notice. This is done rather for order in the code. There is no need to store something that is not used and will definitely not be used.

Also in .git are all WP-plugins that are used. On our site it is Google XML Sitemaps, RSS for Yandex Turbo, RusToLat and WP-PostViews.

The static, rolled-up prototype of the blog pages and source files were moved to the blog theme directory: so that it was convenient to interact with the logical part of the template and with all that is responsible for the appearance and behavior of elements on the page.

A static version of the project build - with source codes and all dependencies in the first attempt to organize the structure - was placed in the themes directory.

That is, next to the main theme of bsp , the /app directory has been added, which contains the source code for the theme layout and the gulp-builder. But in this version there was one tricky moment: static files were generated in a separate directory, and for the changes to be in the WP theme, you had to copy static style files and scripts to the assets folder inside the theme.

The second approach: a new version of the structure

In the first weeks this was decided by a simple console script, which copied the collected files from a static theme into a WP-theme. Superfluous action leads to errors. Therefore, the option was only to correct the structure.

We have three important directories (all the way from the root):

1. WP-Theme: /wp-content/themes/bsp
2. Static theme sources: /app
3. Compiled static topic: /dist

And inside it are assets with style files, graphics and JS.

You need to arrange everything in such a way that the statics of stylesheets and scripts are collected in the correct folder ( /wp-content/themes/bsp/assets ).

The new version of the structure was as follows:

  Ulp── gulpfile.js / # Gulp-tasks for building
 W── wp-content / # Custom WordPress site files
 Plug ├── plugins / # wp-plugins
 │ ├── themes / # Site Themes
 │ │ ├── bsp / # PromoPult Blog Topic
 │ │ │ ├── app / # Sources for a static theme
 │ │ │ ├── assets / # Resources: JS, CSS, and graphics (autogeneration)
 │ │ │ ├── home.php #Blog home page and other files in the root of the topic
 W── wp-admin / # WP files for admin panel
 W── wp-includes / # WP system files 

At the root of the whole project are gulp-tasks - and executed from the root. The gulp-tasks configuration describes the structure that static files are collected from the wp-content/themes/bsp/app directory in wp-content/themes/bsp/assets without any additional actions like copying, etc.

WP-theme files remain unchanged and work proceeds according to the old scenario: editing in statics → transfer to WP-files. Statics CSS and JS is generated immediately in the folder with the theme and everything just works.

All this was about the process of work. Now, about how the blog itself is arranged.

Blog PromoPult: how everything works

The main strength of the blog - the team. Editor, authors, layout designers.

The big task is to make working with blog content convenient in the admin area. And taking into account the fact that the topic of our blog was made specifically for content tasks and editorial requests, the admin panel was updated accordingly.

Check list before publication

Any work is important to control. The layout of the article is a standard, formalized process that can be easily represented as a check list.

The idea saw the guys from EmailSoldiers . We decided to apply it at home.

If any item is not marked - the system will warn before publication.

By clicking on the links, underlined links in the list item - we highlight a specific item.

The check list is compiled in the same order as the additional post settings in the admin panel.

Post settings in the admin of the blog

Closely intertwined with the check list of the publication described above.

When developing a theme, I tried not to use plug-ins, but to make a simple and easy solution for the problems of the theme. Highlights:

• Descriptions for SEO meta tags.
• Descriptions for OpenGraph tags that use social networks when sharing material and form nice cards of articles.
• Convenient work with pictures, covers for posts. One picture is obligatory - it is added to the post card in the posts tile, which is displayed on the main page and on the rubric or tag page.
• Additional theme settings: a post can be with or without a cover, there is a short text-announcement, which we show in a cap with a cover, and it is also used in the description of the article in the digest list.

Post settings section is implemented through meta boxes and custom fields in WordPress.

Through the meta-box added and checklist publication.

In templates, working with fields is simple: if a field is not empty and filled in, we retrieve the value and show it. For example, this is how a block reaction to a post is displayed:

 <?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 } ?> 

An example of the output of the reaction on the post card:

Pleasant trifles

There are some nice little things that maybe no one sees. But if someone noticed - well.

For example, the publication date of the post in the cards and in a separate post in our Cyrillic alphabet and can bend. For some reason, this is not in the WordPress box. If the publication date is in the current year, then the year is not shown here, if the year is different from the current one - the date is shown together with the publication year.

Post comments counter. Long argued that "0 comments" or "no comments" is very confusing. The solution is very simple: do not show the comment count at all, if there are less than one comment.

In general, we are working separately on the comment system and would like to talk about this in a separate big post. We make a simple and convenient commenting system with simple authorization through social networks.

Your own likes: commenting or sharing links in social networks is a long matter by the standards of the rate of content consumption, but clicking on the “like” and making it clear that the article is cool is simple and fast. We made our simple likes and put the counter in the post card. And huskies arrive pretty quickly. And since they stand at the bottom of the article - it is also a signal that the text read.

Made a dark theme for your blog - now it is fashionable. Taking into account the modular structure (in fact, the site is a set of blocks that are somehow combined with each other) and the organization of styles turned out pretty quickly.

About interesting technical

The topic has a minification code markup, CSS and JS. CSS and JS are compressed through gulp-tasks in the statics collector, but the markup minification is done via WordPress-hook WP_HTML_Compression .

And in the comments in the markup, we added a promotional code for those who are interested in how the site is designed from the inside and who first goes to watch the source code:

Caching CSS and JS. So that the stylesheets and scripts are cached, but they are always relevant if we redo something, we use filemtime (). Many then use ?<?php echo time(); ?> ?<?php echo time(); ?> . But this option loads the file and makes a request with each call.

It is better to use this trick:

 <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'); ?>" /> 

In this case, the files will be downloaded if they have been changed, and the date of the file change will be added to the query parameter.

What plugins are used

Despite the possibility and desire in some cases to get by with our solution, we still use plugins. Our list is:

• Google XML Sitemaps - to generate an XML sitemap for robots;
• RSS for Yandex Turbo - turbo pages for Yandex;
• RusToLat - transliteration of Russian characters URL into English;
• WP-PostViews - counts material views;
• Classic Editor - includes the classic WordPress editor instead of the new block Gutenberg;
• The limitation of authorization attempts is for security: in case of several erroneous login attempts, to ban a login for a customizable period of time;
• AMP - AMP Pages for Google.

Tips-conclusions for those who work on the company's blog

• I advise you at the beginning of work on the project to immediately think about scaling.
• Be sure to use .git at work. For 2019, of course, strange advice, but this advice can save someone from gray hair and reprimand when something goes wrong.
• It is better to divide the development and work on the WordPress theme into two stages: first, to impose something static, and already “tense” it as a WordPress theme.
• If there is an opportunity - time, team and understanding of why you need all this - make the topic yourself, without using ready-made options. Win in the order and understanding of how everything works. You will not produce crutches.
• Use standard hooks and WordPress features if your blog is built on it. Customizing and making a convenient solution is quick and easy.
• Make it convenient for users and editors.
• Do not forget about social networks and microdata.
• Do not forget about the mobile version.
• Do not forget about regular updates of plug-ins and system.
• Choose only proven plugins.

Work on the blog continues - stay with us.