Category: Backend Processes

Паспорт проекту

Для кожного проекту в Jira всі відомі доступи збираються в розділі "Паспорт проекту":

• посилання на git репозиторій проекту

• доступи до адміністративної панелі staging сайту

• SFTP доступи до staging сайту

• доступи до БД staging сайту

• усі доступи до Live сайту, що надав нам клієнт (включаючи панель хостингу)

• доступи або інтеграційні ключі до сторонніх сервісів, які необхідні в розробці або інтеграції.

Посилання зазвичай розташоване в бічній панелі проєкту:

Доступ до stage сайтів

Панель хостингу stage сайтів

PhpMyadmin

Інформація про тему

Структура папок

• frontend/assets/ – css, js, зображення, js бібліотеки, шрифти...

  • backend/ - якщо BE розробнику необхідні свої стилі (поза стандартною збіркою)

    • css/

    • js/

  • css/

  • images/

  • js/

  • libs/

  • fonts/

• acf-blocks – Папка зi згенерованими ACF блоками

• acf-options – Папка зi згенерованими ACF сторінками опцій

• acf-pages – Папка зi згенерованими page templates та ACF полями

• includes – основний функціонал теми

  • config – конфігурація теми

    • config.php – конфігураційний масив з усіма налаштуваннями теми

    • styles-and-script.php – підключення стилів і скриптов

  • core - ядро теми

    • setup-theme.php – встановлення теми

    • functions.php – функції ядра та ajax обробники

    • GENERAL_CLI.php – WP CLI команди для теми

    • security.php – безпекові заходи

  • modules – модулі (наприклад налаштування пошуку, шорткоди чи змiна структури меню)

  • acf.php – зміна функціональності плагіну ACF Pro

  • helpers.php – допоміжні функції

• template-parts

• 404.php

• footer.php

• functions.php

• header.php

• index.php

• page.php

• screenshot.png

• search.php

• single.php

• style.css

WP CLI команди для роботи з темою

Створення acf блоків для гутенберг (add_block)

Приклад

wp general add_block "Hero" --fields="Title test",description:textarea,list:repeater[text,descr:textarea],checklist:checkbox[first,last],bg:image,sel:select[A,B,C]

Структура папок

• acf-blocks

  • назва-блоку

    • index.php - Шаблон блоку (створюється автоматично)

    • preview.jpg - прев'ю блоку (яке відображається в редакторі Gutenberg). Приблизна ширина посадкового місця прев'ю 450px

      

      

    • block.json - структура блоку

Приклад файлу block.json

{
	"name": "acf/Назва-блоку",
	"title": "Назва блоку",
	"description": "Опис блоку",
	"version": "1.0.0",
	"category": "sections",
	"icon": "admin-page",
	"example": {
		"attributes": {
			"mode": "preview",
			"data": { "preview": true }
		}
	},
	"acf": {
		"mode": "edit",
		"postTypes": ["page","post"],
		"renderTemplate": "index.php"
	},
	"custom_scripts": [ "/js/{FileName}.min.js" ],
	"custom_styles": [ "/css/{FileName}.min.css" ]
}

Custom recourses

Створення сторінок з шаблоном і ACF полями (add_page)

Приклад

wp general add_page "Contact us" --fields=title,description:textarea

Опис

Буде створений шаблон, сама сторінка з назначеним цим шаблоном, створені ACF поля для цієї сторінки та підключений код ACF до цього темплейту.

Структура папок

• acf-pages

  • Назва сторінки

    • template.php - Шаблон сторінки

    • index.php - Додаткові поля сторінки

ACF поля для add_page, add_option, add_block

Атрибути

--fields

Формат

Назва-поля:Тип-поля (якщо тип поля не вказаний то тип поля ставиться text, якщо назва поля складається з більш ніж одного слова то воно обромляється подвійними лапками)

Типи полів

textarea - Текстове поле

editor - Текстове поле

email - Email

link - Link

repeater[тут так само описуються поля]

checkbox[A,B,C] - де A B C - список

radio[A,B,C] - де A B C - список

select[A,B,C] - де A B C - option

image - Зображення

true_false - True-false чекбокс

Деякi особливостi

Створення власних Post Types та Taxonomies

Створення сторінок ACF опцій

Для зручності в admin bar було додано веидення поточних сторінок (зі збереженням ієрархії)

ACF блоки

Під час генерації ACF блоку необхідно в файлi block.json вказати йому зрозумілу назву, зрозумілий опис і завантажити прев'ю (в ідеальному випадку було б чудово і ще вказати відповідну іконку).

Назва ACF блоку

Опис ACF блоку

Превью блока

Додавання SVG іконок

Якщо необхідно вставити svg іконку, яка не потребує редагування із адміністративної частини сайту, то необхідно вивести шаблон:

template-parts/partials/social-icons.php

Наприклад для іконки search.svg

get_template_part('template-parts/partials/sprite', 'icon', [ 'icon' => 'search' ]); 

В цьому випадку скрипт підвантажить зібраний sprite.svg

<svg class="icon icon_search">
	<use href="../wp-content/themes/general/frontend/assets/icons/sprite.svg?v=1.0#search"></use>
</svg>

Якщо необіходно дадати можливість вибору іконки в адміністративній частині файлу (як показує практика - для роботи з полями типу repeater):

• Обов'язково створити поле під назвою theme_icons і вибрати тип select, checkbox або radio

• В цьому випадку спрацює метод che_acf_load_field_theme_icons із файлу includes/acf.php

• Для значень цього поля (choises) автоматично підтягнуться усі існуючі іконки *.svg із папки frontend/src/icons/, після чього можно буде вибрати необхідну іконку. Якщо будуть додані нові іконки, то вони також покажуться у списку значень.

Для зручності і наглядності підвантажуються самі іконки для всіх типів полів

Робота із зображеннями

При роботі із зображеннями може виникнути необхідність додати проміжні розміри зображень для різних брейкпоінтів - розмірів екрану. Наприклад, на великих екранах у вас є 4 зображення в ряд, розміром 300x300px, а на мобільній версії вони перебудовуються в колонку і зображення розтягується на 100%. В цьому випадку, якщо ви явно вказали розмір ['300', ‘300’] - ви отримаєте зображення поганої якості на екранах більшої роздільної здатності, ніж розмір зображення.

Аби цього уникнути, можна використати параметр ['custom_srcset'] де через крапку з комою вказати бажані розміри зображень для різних розмірів екрану. У цьому випадку WordPress згенерує зображення за вашими розмірами і обиратиме для завантаження оптимальне з наявних.

Наприклад

echo wp_get_attachment_image($image['ID'], [300, 300], false, ['custom_srcset' => '750,700;550,500']

functions.php

Додавання своїх констант

define( 'MY_CONSTANT', 'MY_CONSTANT_VALUE' );

Підключення *.php файлів. Файли, які підключаються, мають бути "спеціалізованими", наприклад:

• для модифікації функціоналу WooCommerce

• створення завантажувача CSV-файлів на сторінці налаштувань

require_once THEME_MODULES_DIR . '/woo-customize.php';
require_once THEME_MODULES_DIR . '/csv-loader.php';

wp-config.php

Для перевірок робочого оточення необхідно використовувати функцію wp_get_environment_type:

• Для локального сайту Local WP автоматично проставляє значення local

• Для stage сайту автоматично встановиться значення staging

• Для production сайту необхідно буде вручну вказати значення production

$is_local      = strpos( $server_name, 'local' ) !== false;
$is_cheapgroup = strpos( $server_name, 'cheitgroup' ) !== false;

Покращення теми

Якщо у Вас є ідея як можна поліпшити\оптимізувати тему, то Ви можете запропонувати це наступним чином:

1. Склонувати проект (або оновити до актуального стану поточний)

2. З гілки stage створити нову гілку (назва гілки - короткий опис поліпшення, наприклад change-block-preview)

3. Зробити коміт та опублікувати гілку

4. Створити merge request у гілку stage та додати інформацію в поле Description (якщо це необхiдно)

5. Якщо код пройде рев'ю Тех\Тим Лідом, Ваш merge request буде схвалено. Пiсля цього покращення буде автоматично опубліковано в архіві теми

Сайт - Local

Для работоби з WP сайтами Local має безліч переваг в порівнянні з іншими подібними програмними продуктами (такі як OpenServer чи Mamp):

• можливість запустити сайт на WP в “декілька кліків”

• можливість імпорту сайт з архіву, який було створено плагіном WP Migrate

• можливість сайту з архіву нашої стартової теми

• можливість комбінувати тип Web серверу + PHP version + MySQL version

• можливість моментально створили сертифікат для локального домену и працювати через протокол https

• можливість працювати в адміністративному розділі без авторизації, функція “One-click admin”

• можливість змiнювати URL локального домену в “декілька кліків”

• можливість відстежувати відправлені Email листи через MailLog

• можливість експорту\імпорту сайту зі збереженням налаштувань Web серверу та WordPress

• та багато іншого, з усіма можливостями можно ознайомитись тут Features

Стандартна конфігурація локального сервера

PHP

Мінімальна версія 8.0.

Необхідно стежити за тим, щоб локальна версія PHP і версія на staging сайті були однаковими!

Web Server

Apache. Для більш гнучкого налаштування і підтримки .htaccess файлів

MySQL

Найостанніша доступна версія. На даний момент це 8.0.16

Импорт готового сайту (з архiву)

Далі вбиваємо назву сайту і обираємо налаштування, які вказані нижче

Вбиваємо доступи і вказуємо налаштування мультисайтності (якщо це необхідно)

WP CLI

Local “із коробки” має переустановлений i налаштований WP CLI, достатньо натиснути Open Site shell

Cхема роботи

Cхематично наш flow можна подивитись нижче↓ за посиланням можна подивитись тут

Відгалуження

*MR - merge request

*PR - pull request

*CR - Code Review

Основні гілки

На всіх проектах завжди присутні 2 основні гілки master і stage.

master- основна гілка проекту. З неї починається будь-яка нова вхідна задача, з неї вона потрапляє на production сайт (цей процес ще поки що не автоматизований). У більшості випадків ми відштовхуємося від того, що код у гілці master і код на production сайт однаковий.

stage- гілка для тестування виконаних задач. Код із цієї гілки протягом кількох хвилин після MR автоматично потрапляє на staging сайт.

production- спеціальна гілка для того, щоб код автоматично потрапляв потрапив на production сайт.

Інші гілки

features/JS-8- основна гілка окремої задачі. Назва гілки береться строго з коду задачi в Jira.

bugfix/JS-8- основна гілка окремої задачі де треба пофіксити баг, який було знайдено на сайті.

Назва гілки береться строго з коду задачi в Jira. Знайти цей код можна тут:

Порядок роботи

1. На Вас як розробника в Jira приходить задача в колонку TO DO або OPEN - її потрібно перевести в колонку IN PROGRESS

2. У локальній копії сайту створити нову гілку з гілкиmaster (наприклад features/JS-8)

3. Виконати задачу та опублікувати гілку features/JS-8 з коммітом у репозиторії проекту.

4. Зробити MR гілкиfeatures/JS-8 в гілку stage:

   • features/JS-8 не видаляємо!

     

   • після чого запуститься процес автоматичного деплою на staging сайт. Перевірити це можна в розділі Built → Jobs:

     

5. Перевірити працездатність виконаної задачі на staging сайті (за необхідності створити сторінку\пост, заповнити тестові дані тощо)

6. Якщо на staging сайті ввімкнено кешування (зазвичай це плагін WP Rocket), то необхідно:

   • очистити кеш на всьому сайті (якщо це мультисайт - то необхідно очистити кеш на всіх сайтах окремо)

   • відключити плагін кешування (тільки в тому випадку, якщо плагін не важливий для поточного завдання)

7. Змінити статус задачi на CODE REVIEW (у деяких випадках для CODE REVIEW може бути окремий стовпчик)

   • Обрати виконуючим відповідального за перевірку коду (CR) (зазвичай це Тім\Тех лiд)

   • У коментарях залишити:

     • посилання на MR у гілку stage

     • посилання на сторінку staging сайту, де велася робота

     • додати коментар, якщо необхідно на щось звернути увагу.

8. Після виконаного CR може бути 2 варіанти:

   • Задача буде повернута на доопрацювання. У коментарях буде вказано причину цього + у самому MR будуть вказане посилання на код, який необхідно змінити\поправити\доопрацювати. У такому випадку задача залишається в колонці CODE REVIEW. Робочу процедуру необхідно буде повторити:

     • У локальній копії сайту в гілці features/JS-8 доопрацювати задачу

     • Зробити новий коміт і опублікувати його в репозиторії

       • У назві коміту(ів) потрібно додати строку “After CR day.month: message”.
         Наприклад After CR 13.09: fixing news section

     • Зробити MR у гілку stage

   • Задача успішно пройшла CR. Необхідно буде зробити наступне:

     • Зробити MR features/JS-8 у гілку master

     • Цього разу необхідно поставити галочку “Delete source branch…”, щоб гілка features/JS-8 була видалена пiсля завершення MR.

     • Переконатися в успішному (безконфліктному завершенні) MR.

     • Перемістити задачу в колонку READY FOR QA (інколи READY FOR TESTING)

     • Призначити виконавцем PM проекту

   • У разі успішного проходження QA, задача буде переміщуватися далі по дошці Jira (за це вже відповідає PM або QA)

   • Якщо QA знайде помилки, то необхідно буде повторити робочий цикл: задача переміщується в колонку TO DO або OPEN, і Ви призначаєтесь виконавцем.

Робота з гілкою production

Якщо в гіт репозиторії є гілка production - це означає те, що для цього проєкту налаштовано автоматичний деплой на production сайт. У більшості випадків це зроблено за допомогою протоколу LFTP.

Для того, щоб усе спрацювало, Вам необхідно просто MR з гілки master в гілку production. Статус деплою буде доступний в розділі Built → Jobs (з тегом deploy_production):

Список типів робіт, які необхідно передавати на CR

1. Якщо повністю була закінчена сторінка з декiлькома блоками

2. Блоки, які включають в себе роботу з js бібліотеками (slider, swiper і т.д)

3. Наявність ajax функціоналу

4. Наявність форм у блоці або на сторінці

5. Будь-яка API інтеграція

6. Будь яка бага, яка прийшла від клієнта!