Forem: Андрей Викулов (VProger)

Как создать блог на Astro: установка, MDX, Content Collections

Андрей Викулов (VProger) — Tue, 21 Apr 2026 18:21:53 +0000

Как создать блог на Astro: полная инструкция

Проблема: нужно быстро поднять быстрый блог или контентный сайт с хорошим SEO, но без сложностей Next.js и без перегруженного JavaScript.

Решение: Astro — статический генератор (SSG), который рендерит HTML по умолчанию и добавляет интерактивность точечно (islands architecture). В итоге получается лёгкая страница, понятная поисковикам и пользователям.

В этой статье — пошаговая настройка блога на Astro: установка, структура проекта, маршруты, MDX (Markdown с компонентами) и Content Collections со схемой на Zod для валидации контента.

В чём проблема: выбор фреймворка для контентного сайта

Если нужен блог, документация или маркетинговый сайт, есть три основных варианта:

|----------|-------|---------|--------|

Вывод: для блога, документации или маркетингового сайта Astro часто даёт самый лёгкий результат при минимальном JavaScript.

Рабочее решение: пошаговая настройка

Шаг 1: Создание проекта Astro


Официальный способ: интерактивный мастер

npm create astro@latest

или

pnpm create astro@latest

Мастер спросит:

Шаблон (выбери blog для блога или minimal для чистого старта)
TypeScript (рекомендуется включить — пригодится для Content Collections)
ESLint и форматирование (по желанию)

Шаг 2: Проверка системных требований


Проверить Node.js (должно быть >= 18)

node -v

Проверить менеджер пакетов

npm -v # или pnpm -v / yarn -v

Требования:

Node.js 18+ (рекомендуется LTS: 20 или 22)
npm, pnpm или yarn
Редактор кода (VS Code + плагин Astro)

Шаг 3: Запуск dev-сервера


Перейти в папку проекта

cd <имя-проекта>

Запустить dev-сервер

npm run dev

или

pnpm dev

Открой http://localhost:4321 — должен открыться стартовый сайт.

Шаг 4: Проверка сборки перед деплоем


Собрать проект в папку dist/

npm run build

или

pnpm build

Если сборка прошла без ошибок — проект готов к деплою.

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

Типичная структура блога на Astro:


/

├─ astro.config.mjs # Конфигурация Astro

├─ package.json # Зависимости и скрипты

├─ src/

│ ├─ pages/ # Маршруты (file-based routing)

│ │ ├─ index.astro # Главная страница

│ │ ├─ about.astro # /about

│ │ └─ blog/

│ │ ├─ index.astro # /blog (список статей)

│ │ └─ [slug].astro # /blog/:slug (страница статьи)

│ ├─ layouts/ # Layouts (общая обвязка)

│ │ └─ BaseLayout.astro

│ ├─ components/ # UI компоненты

│ │ └─ Callout.astro

│ ├─ content/ # Контент (Content Collections)

│ │ └─ blog/ # Статьи блога

│ └─ styles/ # Глобальные стили

└─ public/ # Статика (копируется как есть)

└─ favicon.svg

Правило маршрутизации: файл в src/pages/ = маршрут.

src/pages/index.astro → /
src/pages/about.astro → /about
src/pages/blog/[slug].astro → /blog/:slug

Первый layout: BaseLayout.astro

Создай файл src/layouts/BaseLayout.astro:


---

// Пропсы приходят со страницы; задаём значения по умолчанию

const {

title = "Site",

description = "Astro site",

} = Astro.props;

---

<!doctype html>

<html lang="ru">

<head>

<meta charset="utf-8" />

<meta name="viewport" content="width=device-width, initial-scale=1" />

<title>{title}</title>

<meta name="description" content={description} />

</head>

<body>

<header style="padding:16px; border-bottom:1px solid rgba(255,255,255,.1)">

[Главная](/)

<span style="opacity:.6; margin-left:8px">|</span>

[Блог](/blog)

</header>

<main style="max-width: 860px; margin: 0 auto; padding: 24px;">

<slot />

</main>

<footer style="padding:16px; border-top:1px solid rgba(255,255,255,.1); opacity:.7">

© {new Date().getFullYear()}

</footer>

</body>

</html>

— это "сюда вставится содержимое страницы".

Первая страница: index.astro

Создай файл src/pages/index.astro:


---

import BaseLayout from "../layouts/BaseLayout.astro";

---

<BaseLayout title="Главная" description="Стартовый проект на Astro">

# Привет, Astro

Если страница открылась — ты уже в деле.

</BaseLayout>

Открой http://localhost:4321 — должна отобразиться главная страница.

Подключаем MDX: Markdown с компонентами

Установка MDX

MDX — это Markdown, который умеет встраивать компоненты и JS-выражения.


npx astro add mdx

или

pnpm astro add mdx

После установки в astro.config.mjs появится интеграция @astrojs/mdx.

Первая MDX-страница

Создай файл src/pages/guide.mdx:


---

title: "Гайд по Astro"

description: "Пробная MDX-страница"

---

MDX в Astro работает ✅

Это обычный Markdown… но с бонусами.

- списки
- код
- и компоненты ниже

Открой /guide — должна отрендериться страница.

Встраиваем компоненты в MDX

Создаём компонент Callout.astro

Создай файл src/components/Callout.astro:


---

const { type = "info", title = "Важно" } = Astro.props;

const styles = {

info: "background: rgba(0, 180, 255, .08); border: 1px solid rgba(0, 180, 255, .35);",

warn: "background: rgba(255, 180, 0, .08); border: 1px solid rgba(255, 180, 0, .35);",

danger: "background: rgba(255, 80, 80, .08); border: 1px solid rgba(255, 80, 80, .35);",

};

---

<section style={padding: 14px 16px; border-radius: 12px; ${styles[type] ?? styles.info}}>

<strong style="display:block; margin-bottom: 6px">{title}</strong>

<div><slot /></div>

</section>

Используем компонент в MDX

Обнови src/pages/guide.mdx:


---

title: "Гайд по Astro"

description: "Пробная MDX-страница"

---

import Callout from "../components/Callout.astro";

MDX + компоненты

<Callout type="info" title="Смысл MDX">

Ты пишешь статью как Markdown, но можешь вставлять "живые" компоненты.

</Callout>

<Callout type="warn" title="Пара слов о порядке">

Не превращай статью в React-приложение. Это всё ещё контент.

</Callout>

Content Collections: контент с валидацией

Зачем нужны collections

Чтобы:

Описать схему фронтматтера (какие поля обязательны)
Ловить ошибки на этапе билда (а не в проде)
Получать типизацию (особенно приятно в TS)

Настраиваем src/content.config.ts

Создай файл src/content.config.ts:


// src/content.config.ts

import { defineCollection } from "astro:content";

import { z } from "astro/zod";

const blog = defineCollection({

schema: z.object({

title: z.string().min(5),

description: z.string().min(20),

pubDate: z.date(),

updatedDate: z.date().optional(),

tags: z.array(z.string()).default([]),

category: z.string().default("Frontend"),

draft: z.boolean().default(false),

cover: z.string().optional(),

slug: z.string().min(3),

}),

});

export const collections = { blog };

astro/zod — это реэкспорт Zod для схем коллекций.

Первая статья в коллекции

Создай файл src/content/blog/astro-part-1.mdx:


---

title: "Astro: старт (часть 1)"

description: "Статья в content collection, чтобы потом красиво собрать список и страницы."

pubDate: 2026-01-05T16:00:00.000Z

tags:

- astro
- mdx
- frontend

category: Frontend

draft: false

slug: "astro-part-1"

---

import Callout from "../../components/Callout.astro";

Astro: старт (часть 1)

<Callout type="info" title="Это пост из коллекции">

Он лежит в src/content/blog и валидируется схемой.

</Callout>

Здесь начинается содержание статьи…

Выводим список статей: /blog

Создай файл src/pages/blog/index.astro:


---

import BaseLayout from "../../layouts/BaseLayout.astro";

import { getCollection } from "astro:content";

// Загружаем все посты, скрываем черновики, сортируем по дате

const posts = (await getCollection("blog"))

.filter(p => !p.data.draft)

.sort((a, b) => b.data.pubDate.valueOf() - a.data.pubDate.valueOf());

---

<BaseLayout title="Блог" description="Список статей на Astro">

# Блог

{posts.map((post) => (

- [{post.data.title}]({/blog/${post.data.slug}/})

))}

</BaseLayout>

Страница статьи: /blog/:slug

Создай файл src/pages/blog/[slug].astro:


---

import BaseLayout from "../../layouts/BaseLayout.astro";

import { getCollection } from "astro:content";

// Для SSG Astro нужен список всех путей

export async function getStaticPaths() {

const posts = await getCollection("blog");

return posts

.filter(p => !p.data.draft)

.map((post) => ({

params: { slug: post.data.slug },

props: { post },

}));

}

const { post } = Astro.props;

// У коллекционных MDX/MD есть render() — получаем компонент контента

const { Content } = await post.render();

---

<BaseLayout title={post.data.title} description={post.data.description}>

<article>

# {post.data.title}

{post.data.pubDate.toLocaleDateString("ru-RU")}

<Content />

</article>

</BaseLayout>

Проверка результата

Проверка списка статей


Запустить dev-сервер

npm run dev

Открыть http://localhost:4321/blog

Должен отобразиться список статей из src/content/blog/.

Проверка страницы статьи


Открыть http://localhost:4321/blog/astro-part-1/

Должна отобразиться страница статьи с содержимым MDX.

Проверка сборки


Собрать проект

npm run build

Проверить dist/

ls -la dist/

Если сборка прошла без ошибок — все маршруты и коллекции настроены верно.

Типичные ошибки

❌ Ошибка: getCollection("blog") — коллекция не найдена

Причина: Нет src/content.config.ts или папки src/content/blog/.

Решение:


Создать конфиг

touch src/content.config.ts

Создать папку для статей

mkdir -p src/content/blog

❌ Ошибка валидации frontmatter при билде

Причина: Поля не совпадают со схемой (дата, обязательные поля).

Решение: Проверить title, description, pubDate, slug в .mdx. Даты в формате ISO: 2026-01-05T16:00:00.000Z.

❌ MDX-страница не открывается / 404

Причина: Файл не в src/pages/ или опечатка в имени.

Решение: Роут = путь от pages: guide.mdx → /guide.

❌ Компонент в MDX не найден

Причина: Неверный путь импорта (относительно файла MDX).

Решение: Импорт от корня файла: ../../components/Callout.astro.

❌ post.render is not a function

Причина: Используется сырой объект поста вместо результата getCollection.

Решение: В [slug].astro брать post из getStaticPaths → props и вызывать post.render().

Где применять

Блоги: контентные сайты с MDX и Collections
Документация: техническая документация с компонентами
Лендинги: маркетинговые страницы с быстрым SEO
Портфолио: сайты-визитки с минимальным JS

Связанные статьи:

SEO, sitemap и RSS в Astro
Actions, API Routes, SSR и деплой
TypeScript: основы и философия

Документация:

Read more on viku-lov.ru

Как конвертировать CHM в один PDF на Linux: без мусора и битых ссылок

Андрей Викулов (VProger) — Sat, 28 Feb 2026 08:04:06 +0000

Как конвертировать CHM в один PDF на Linux: без мусора и битых ссылок

Если у тебя есть bsm_api.chm и нужно получить один нормальный PDF , а не «папку из 900 HTML + слёзы», вот рабочий пайплайн: CHM → HTML → (сборка) → PDF.

В конце будет:

один manual.pdf
без битых внутренних ссылок (насколько позволяет исходник)
с нормальной навигацией/оглавлением (если CHM адекватный)

В чём проблема

CHM — это не “один файл с текстом”, а контейнер: HTML + картинки + оглавление + внутренние ссылки.

Типовые боли:

конвертеры делают 1000 страниц вместо одного PDF
ломают ссылки и кодировки
получаешь PDF, который выглядит как скриншоты из 2007

Рабочее решение

1) Установка инструментов

Ubuntu/Debian:


sudo apt update

sudo apt install -y \

extractchm \

wkhtmltopdf \

python3 \

python3-bs4 \

python3-lxml

Если extractchm нет (редко, но бывает), ставим из chmlib:


sudo apt install -y chmlib-tools

потом будет утилита extract\_chmLib

Проверка:


extractchm -h || true

wkhtmltopdf --version

2) Распаковать CHM в HTML

Создай рабочую папку:


mkdir -p ~/work/chm2pdf/{src,html,out}

cp bsm\_api.chm ~/work/chm2pdf/src/

cd ~/work/chm2pdf

Распаковка:

Вариант A (extractchm):


extractchm -o html src/bsm\_api.chm

Вариант B (extract_chmLib):


extract\_chmLib src/bsm\_api.chm html

Проверка что распаковалось:


ls -la html | head

find html -maxdepth 2 -type f | head

3) Найти “точку входа” (главную страницу)

Обычно это index.html, default.html, start.html или что-то из оглавления.

Быстрый поиск кандидатов:


ls html | grep -iE 'index|default|start|main' || true

Если не очевидно — ищем самый “толстый” HTML:


find html -type f -iname '\*.html' -printf '%s\t%p\n' | sort -n | tail -20

4) Собрать единый HTML (важный шаг)

wkhtmltopdf лучше работает, когда ты отдаёшь ему одну HTML-страницу , а не тысячу.

Сделаем “склейку”: берём список страниц и собираем в out/merged.html.

Вот минимальный Python-скрипт, который:

читает оглавление (если найдём файл типа .hhc/toc)
если оглавления нет — склеивает HTML по алфавиту (хуже, но работает)
вырезает мусорные script/iframe
приводит относительные ссылки к локальным путям

Создай файл tools/merge.py:


#!/usr/bin/env python3

import os

import re

from pathlib import Path

from bs4 import BeautifulSoup

ROOT = Path("html").resolve()

OUT = Path("out")

OUT.mkdir(parents=True, exist\_ok=True)

def list\_html\_files():

1) Если есть оглавление — можно допилить парсер под конкретный CHM

2) Универсальный fallback — склеим HTML по имени

files = sorted(ROOT.rglob("\*.html"))

выкинем дубли/служебное

files = [p for p in files if p.is\_file() and p.stat().st\_size > 200]

return files

def clean\_body(html\_path: Path) -> str:

data = html\_path.read\_bytes()

грубая попытка с кодировкой

for enc in ("utf-8", "cp1251", "windows-1251", "latin-1"):

try:

text = data.decode(enc)

break

except UnicodeDecodeError:

continue

else:

text = data.decode("utf-8", "ignore")

soup = BeautifulSoup(text, "lxml")

выкидываем потенциальный мусор

for tag in soup(["script", "iframe", "noscript"]):

tag.decompose()

body = soup.body or soup

нормализуем якоря и локальные ресурсы

for a in body.find\_all("a", href=True):

href = a["href"].strip()

убираем внешние и mailto

if href.startswith(("http://", "https://", "mailto:")):

continue

normalize windows slashes

a["href"] = href.replace("\\", "/")

добавим заголовок-разделитель

title = soup.title.get\_text(strip=True) if soup.title else html\_path.name

header = f"

# {title}
\n"

return header + str(body)

def main():

parts = []

for p in list\_html\_files():

try:

parts.append(clean\_body(p))

except Exception as e:

print(f"skip {p}: {e}")

merged = f"""<!doctype html>

<html>

<head>

<meta charset="utf-8" />

<title>CHM merged</title>

<style>

body {{ font-family: Arial, sans-serif; line-height: 1.45; }}

pre, code {{ white-space: pre-wrap; word-wrap: break-word; }}

h1 {{ page-break-before: always; }}

</style>

</head>

<body>

{''.join(parts)}

</body>

</html>

"""

(OUT / "merged.html").write\_text(merged, encoding="utf-8")

print("OK -> out/merged.html")

if \_\_name\_\_ == "\_\_main\_\_":

main()

Запуск:


mkdir -p tools out

python3 tools/merge.py

ls -la out/merged.html

5) Конвертировать merged.html → PDF


wkhtmltopdf \

--enable-local-file-access \

--encoding utf-8 \

--page-size A4 \

--margin-top 12 --margin-bottom 12 --margin-left 10 --margin-right 10 \

out/merged.html out/manual.pdf

Проверка результата:


ls -lah out/manual.pdf

file out/manual.pdf

Проверка результата

Минимум:

PDF открывается, вес адекватный (не 2 KB и не 2 GB)
есть текст (не “картинки страниц”)
код/таблицы читаются

Быстрый sanity-check: извлечь пару строк текста:


python3 - <<'PY'

import subprocess, sys

p = subprocess.run(["pdftotext", "out/manual.pdf", "-"], capture\_output=True, text=True)

print(p.stdout[:800])

PY

Если pdftotext нет:


sudo apt install -y poppler-utils

Типичные ошибки

❌ 1) “Blocked access to file” / не видит картинки

Причина: wkhtmltopdf по умолчанию режет локальные ресурсы.

Решение: добавь --enable-local-file-access (в примере уже есть).

❌ 2) Кракозябры вместо русского

Причина: HTML в CP1251, а ты склеил как UTF-8.

Решение:

в merge.py мы пробуем cp1251/windows-1251
если всё равно плохо — найди реальную кодировку исходников:


file -i html/\*.html | head

❌ 3) “Оглавление” нет, порядок глав сломан

Причина: CHM хранит структуру в .hhc/.hhk, а мы склеили “по алфавиту”.

Решение: дописать парсер оглавления под конкретный CHM (реально 20–40 строк, если структура нормальная).

Если хочешь — кидай список файлов из html/ (без содержимого), я подскажу точечно.

Где применять

Локально: быстро получить PDF, отдать в LLM/коллегам/заказчику.
CI/CD: автогенерация документации в PDF (если CHM как артефакт).
VPS: можно крутить без GUI, чисто консолью.

Смотри также

Если будешь ковыряться с файлами и поиском по дереву — пригодится:

Поиск файлов в Linux: команды для Ubuntu/CentOS — диагностика и find
find: поиск больших файлов — когда PDF внезапно 900MB
rsync: безопасное копирование с прогрессом — перенос распакованного CHM или готового PDF

Read more on viku-lov.ru

Миграция с WordPress на Bitrix без потери SEO

Андрей Викулов (VProger) — Mon, 23 Feb 2026 19:00:40 +0000

Миграция с WordPress на Bitrix без потери SEO

Поисковый запрос «миграция с WordPress на Bitrix» обычно означает одно: нужно перенести проект без падения трафика и без пересборки индекса с нуля. Статья для тех, кто уже решил перейти на Bitrix и кому важно не потерять позиции и переходы из поиска.

Цель — сохранить структуру URL, метаданные (title, description, canonical), пользователей и поведенческие факторы. Ниже — конкретные шаги: экспорт из БД WordPress, импорт в Bitrix с сохранением slug, настройка ЧПУ и 301, проверка и типичные ошибки.

Сниппеты по статье

Готовые проверенные фрагменты по шагам миграции:

WordPress: экспорт постов и SEO-меты для миграции (SQL) — выгрузка из wp_posts и wp_postmeta
Bitrix: SEF и шаблон URL для блога — настройка ЧПУ с ELEMENT_CODE
Nginx: 301 rewrite при смене структуры URL — постоянный редирект ветки адресов
Bitrix: UrlRewriter — правило 301 редиректа — точечные редиректы через API

В чём проблема

Типичные симптомы при кривой миграции: старые ссылки из поиска и закладок перестают открываться, в панелях вебмастеров растёт число ошибок доступа, трафик из органики падает.

❌ 404 на старых URL
❌ Потеря meta title / description
❌ Слетевшие canonical
❌ Обнулённые позиции в Яндексе и Google
❌ Пользователи не могут авторизоваться

Подробнее про работу WordPress «под капотом» и настройку окружения — в статьях «WordPress: системный cron вместо WP-Cron» и «WordPress: долгая загрузка, TTFB, nginx и PHP-FPM».

WordPress хранит данные в:

wp_posts
wp_users
wp_usermeta
wp_terms
wp_term_relationships
wp_postmeta

Bitrix работает через инфоблоки и таблицы:

b_iblock_element
b_iblock_section
b_user
b_utm_*

Если просто «залить HTML» или перенести только текст без сохранения адресов и метаданных, поисковики перестают считать страницы теми же самыми: меняется URL — теряется история ссылок и поведенческие факторы. В итоге позиции обнуляются, трафик падает. Поэтому миграция без потери SEO — это всегда экспорт структуры (slug, meta, категории), настройка ЧПУ в Bitrix и обязательные 301-редиректы со старых адресов.

Рабочее решение

Миграция делится на 5 этапов: экспорт из WordPress, импорт в Bitrix, настройка URL и ЧПУ, настройка редиректов, перенос пользователей. Каждый этап можно выполнять на копии БД, чтобы не трогать прод до финальной проверки.

Экспорт данных из WordPress
Импорт в Bitrix
Сохранение структуры URL
Настройка 301
Перенос пользователей

Экспорт постов и страниц из WordPress

Нужны посты и страницы из wp_posts и метаданные SEO из wp_postmeta (плагины вроде Yoast или Rank Math хранят там title, description и canonical). Прямой доступ к БД быстрее и надёжнее, чем выгрузка через админку. Оба запроса ниже можно выполнить в phpMyAdmin или из консоли MySQL; результат сохраняем в JSON для следующего шага. Готовый сниппет с пояснениями и ссылками на документацию: WordPress: экспорт постов и SEO-меты для миграции (SQL).


-- Посты и страницы

SELECT ID, post\_title, post\_name, post\_content, post\_date, post\_type, post\_status

FROM wp\_posts

WHERE post\_type IN ('post','page') AND post\_status = 'publish';

-- Мета SEO (title, description, canonical)

SELECT post\_id, meta\_key, meta\_value

FROM wp\_postmeta

WHERE meta\_key IN ('\_yoast\_wpseo\_title', '\_yoast\_wpseo\_metadesc', '\_yoast\_wpseo\_canonical');

Импорт в Bitrix через Python

Пример скрипта (через REST или прямой PHP endpoint):


import requests

import json

with open("wp\_export.json", "r", encoding="utf-8") as f:

data = json.load(f)

for post in data:

payload = {

"IBLOCK\_ID": 5,

"NAME": post["post\_title"],

"CODE": post["post\_name"], # важно для URL

"ACTIVE": "Y",

"PREVIEW\_TEXT": post["post\_content"],

}

requests.post(

"https://staging-site.ru/api/import.php",

json=payload

)

Ключевой момент — поле CODE в Bitrix должно совпадать с post_name из WordPress. Тогда адрес вида /blog/post-name/ останется тем же, и поисковики увидят тот же URL. Импорт можно делать через REST API Bitrix или через свой PHP-скрипт на временном endpoint; в примере выше используется один общий endpoint для всех записей.

Сохранение структуры URL

В WordPress адреса часто выглядят как /blog/post-name/ или /category/design/. В Bitrix нужно явно включить ЧПУ (SEF) и задать шаблон так, чтобы символьный код элемента подставлялся в URL. Создаём раздел с псевдонимом blog, в настройках сайта включаем SEF и указываем папку, например /blog/. Шаблон детальной страницы — #ELEMENT_CODE#/, тогда адрес будет /blog/имя-element-code/. В компоненте списка новостей (например, news) задаём (подробнее — в сниппете Bitrix: SEF и шаблон URL для блога):


"SEF\_MODE" => "Y",

"SEF\_FOLDER" => "/blog/",

"SEF\_URL\_TEMPLATES" => [

"detail" => "#ELEMENT\_CODE#/"

]

301 редиректы

Если часть URL изменилась (например, был /category/, стал /blog/), все старые адреса должны отдавать 301 с новым Location. Иначе поисковики будут считать страницы удалёнными или дублями. Редиректы можно настроить в nginx для массовых правил (один rewrite на целую ветку старых URL) или в Bitrix через UrlRewriter для точечных перенаправлений. Готовые сниппеты: Nginx: 301 rewrite при смене структуры URL, Bitrix: UrlRewriter — правило 301 редиректа. Базовые приёмы nginx — в «Nginx: основы веб-сервера»:


rewrite ^/old-category/(.\*)$ /blog/$1/ permanent;

Или массово через таблицу редиректов Bitrix (модуль «Управление структурой» или API UrlRewriter в том же проекте, где настраивали SEF):


use Bitrix\Main\UrlRewriter;

UrlRewriter::add([

"CONDITION" => "#^/old-url/$#",

"RULE" => "",

"ID" => "",

"PATH" => "/new-url/",

]);

Перенос пользователей

Из WordPress: SELECT ID, user_login, user_email, user_pass FROM wp_users;. В Bitrix создаём пользователей так:


$user = new CUser;

$arFields = [

"LOGIN" => $wpUser["user\_login"],

"EMAIL" => $wpUser["user\_email"],

"PASSWORD" => bin2hex(random\_bytes(8)),

"ACTIVE" => "Y"

];

$user->Add($arFields);

Пароли из WordPress (хеш в user_pass) нельзя подставить в Bitrix: алгоритмы и соль разные. Поэтому при переносе пользователей задаём временный пароль (в коде выше — случайная строка) и при первом входе отправляем пользователю сброс пароля по email либо даём инструкцию сменить пароль в личном кабинете. Так вы сохраните учётки и доступ без взлома старых хешей.

Проверка результата (диагностика)

Диагностика после миграции сводится к трём проверкам: новый URL отдаёт 200, старые адреса отдают 301 с правильным Location, в sitemap перечислены те же URL, что и раньше (или новые, если вы сознательно сменили структуру и настроили редиректы). Команды ниже выполняйте с подставленным вашим доменом.


URL страницы — ожидаем HTTP/1.1 200 OK

curl -I https://site.ru/blog/post-name/

Старый URL — ожидаем 301 Moved Permanently и Location: https://site.ru/new-url/

curl -I https://site.ru/old-url/

Sitemap: URL в файле должны совпадать со старыми

curl https://site.ru/sitemap.xml

Проверка индексации

После переключения прод-домена на Bitrix в Яндекс.Вебмастер и Google Search Console нужно заново отправить sitemap и при необходимости запросить переобход важных URL. Раздел «Покрытие» (coverage) покажет, какие страницы в индексе и нет ли массовых 404. Первые дни возможны временные просадки; если 301 настроены и URL совпадают, через 1–2 недели индекс стабилизируется.

Если не работает

Ниже — частые причины сбоев и что проверить в первую очередь. Если после миграции часть страниц отдаёт 404, трафик падает или пользователи не могут войти — пройдите по пунктам ниже и сверьтесь с разделом «Проверка результата (диагностика)». Чаще всего проблема в пропущенном этапе: забыли мету, поменяли slug или не настроили редиректы. Проверка по чек-листу выше обычно выявляет причину.

Типичные ошибки

❌ Не перенесли meta description

Причина: выгрузили только wp_posts и не учли wp_postmeta, где лежат title, description и canonical от Yoast/Rank Math. Решение: выгрузить мету (запрос выше) и при импорте в Bitrix записывать её в отдельные свойства инфоблока или в отдельные поля; в шаблоне детальной страницы выводить эти поля в

и мета-тегах.

❌ Изменили структуру URL

Причина: в Bitrix включили SEF, но символьный код элемента (CODE) задали произвольно или из названия, а не из post_name WordPress. В итоге адреса отличаются, старые ссылки ведут в никуда. Решение: при импорте строго задавать CODE = post_name для каждой записи и проверять по списку, что URL совпадают.

❌ Не сделали 301

Причина: надеялись, что поисковик «переиндексирует» или что достаточно обновить sitemap. Без 301 старые URL считаются мёртвыми, ссылочный вес и поведенческие факторы не передаются на новый адрес. Решение: для каждого старого адреса настроить 301 на новый (nginx или UrlRewriter в Bitrix), затем проверить через curl -I.

❌ Потеряли теги

Причина: в WordPress теги и категории хранятся в wp_terms и wp_term_relationships; если их не выгрузить и не завести в Bitrix (разделы инфоблока или HighloadBlock), на новом сайте пропадут рубрики и теги. Решение: экспортировать термины и связи, при импорте создавать разделы или записи в HighloadBlock и привязывать элементы к ним.

Где применять

Подход подходит для продакшена при полной смене CMS с WordPress на Bitrix, в том числе в Docker или на BitrixVM (после переноса имеет смысл проверить SSL и при необходимости обновить сертификаты). Особенно важно сохранять URL и 301 для проектов с существенным SEO-трафиком и для интернет-магазинов, у которых блог или статьи переносятся в Bitrix отдельно от каталога. Перед выкатом на прод стоит прогнать все шаги на копии сайта и убедиться, что количество записей, разделов и пользователей совпадает с выгрузкой из WordPress.

Итог

Миграция с WordPress на Bitrix — это не «экспорт-импорт» одной кнопкой, а последовательность: выгрузка постов и меты, импорт с сохранением символьного кода, настройка ЧПУ, 301 и проверка. Если сохранить slug, структуру URL, meta-поля, настроить 301 и актуальный sitemap, позиции не падают. Если хоть один пункт пропустить — получите просадку трафика на 30–70% в первые две недели. SEO здесь сводится к структуре, предсказуемым URL и корректным редиректам: нарушил — заплатил трафиком.

Read more on viku-lov.ru

Почему миграции с WordPress на Bitrix рушат SEO

Андрей Викулов (VProger) — Mon, 23 Feb 2026 18:59:44 +0000

Почему миграции с WordPress на Bitrix рушат SEO

Коротко: SEO падает не из-за смены CMS. Оно падает из-за неправильной архитектуры миграции и игнорирования структуры URL.

За последние годы я участвовал в нескольких переносах проектов с WordPress на Bitrix с трафиком от 50 000 до 300 000 визитов в месяц. В 80% случаев просадка происходила не из-за «плохого Bitrix», а из-за управленческих и архитектурных ошибок. В оставшихся 20% причиной оказывались технические просчёты: не те редиректы, смена адресов «для красоты» или перенос только контента без метаданных. Ниже — о том, в чём именно спор, что происходит в реальности и при каких условиях миграция не бьёт по трафику.

В чём спор

Обычно говорят:

«CMS не влияет на SEO»
«Главное — контент, поисковик разберётся»
«Редиректы можно сделать потом»

Формально доля правды в этом есть: сама по себе система управления контентом не ранжируется. Но то, что из неё следует — URL-модель, структура разделов, скорость ответа сервера и поведение при переезде — уже влияет на индексацию и ранжирование. Поисковые системы реагируют не на название CMS, а на то, остались ли прежними адреса страниц, не посылаете ли вы пользователей и роботов на 404 и не подменили ли вы один документ другим без явного сигнала (301). Игнорировать это — значит заранее закладывать просадку. То же касается тезиса «редиректы потом»: после переключения домена старые URL начинают отдавать 404, ссылочный вес и поведенческие факторы теряются, и «доделать потом» уже не восстанавливает прежнюю картину в глазах поисковика.

Что происходит в реальности

При типичной миграции с WordPress на Bitrix я сталкиваюсь с одними и теми же проблемами:

Меняется структура URL: было «/blog/post-name/», стало «/news/123/» или «/katalog/stati/post-name/»
Теряются slug: в WordPress адрес задаётся полем post_name, в Bitrix — полем CODE; при некорректном маппинге адреса расходятся
Мета-поля не переносятся: title, description и canonical остаются в старой базе или подставляются шаблоном по умолчанию
Не настроены 301-редиректы: старые ссылки из выдачи и с других сайтов оказываются битыми или ведут на временный редирект (302), что не передаёт вес
Sitemap публикуется с задержкой или содержит уже неактуальные URL

В результате поисковик фиксирует: часть страниц пропала, часть появилась по новым адресам, часть ссылок ведёт на 404, canonical изменился. Он не «понимает», что вы переехали; он видит разрыв целостности сайта и переоценивает его. Типичный пример из практики: проект с примерно 120 000 визитов в месяц после «технического переноса» без сохранения slug через три недели снизил трафик примерно до 47 000. Причина — массовые 404 на старых URL и частичные редиректы вместо сквозных 301. В другом кейсе заказчик настаивал на смене структуры каталога «под новую логику»; через два месяца органический трафик упал почти вдвое, и возврат к старой схеме URL с 301 уже не вернул позиции в прежний вид — пришлось выводить сайт из просадки месяцами. Оба случая объединяет одно: решение о миграции принималось без жёсткого требования сохранить адреса и без плана по редиректам.

Когда миграция не убивает SEO

Перенос безопасен для трафика, если соблюдены условия:

Slug полностью совпадает со старым: адрес страницы после переноса тот же, что и в WordPress
Структура вложенности не изменилась: если были разделы и подразделы, они сохраняются в том же виде
Meta title и description перенесены и отображаются в выдаче так же, как раньше (или осознанно улучшены)
Все старые URL отдают 301 permanent на новый адрес, без 302 и без 404
Sitemap обновлён в день релиза и содержит актуальные адреса

В такой постановке CMS вторична: поисковику важна стабильная структура и предсказуемое поведение. Структура и дисциплина первичны; платформа — лишь инструмент. Отсюда практический вывод: перед переездом нужен чёткий чек-лист (выгрузка всех URL, маппинг slug → CODE, перенос мета-полей, настройка 301, обновление sitemap и проверка на staging), и ни один пункт нельзя откладывать «на потом».

Когда я бы не стал переносить проект

Я бы отложил или пересмотрел миграцию в таких случаях:

Если 80% трафика — органика, а бизнес не готов к просадке на 1–2 месяца. Восстановление индекса и доверие после сбоев занимает время; это нужно закладывать в планы
Если нет staging или тестового окружения для полной проверки до переключения прод-домена
Если нет выгрузки всех URL старого сайта: без полного списка адресов невозможно настроить 301 и проверить покрытие
Если команда путает 302 и 301 или не понимает разницы между временным и постоянным редиректом

Миграция с сохранением SEO — это инфраструктурная операция с чёткими критериями приёмки, а не просто «перевёрстка» или «перенос контента». Руководству и заказчику важно заранее принять возможность временной просадки даже при идеальной технике (переобход индекса, обновление сниппетов) и не давить на команду «сделать быстрее» в ущерб проверкам. Сокращение сроков за счёт пропуска этапов почти всегда оборачивается многомесячным восстановлением трафика.

Технический аспект

Без эмоций, только факты:

URL-модель: в WordPress slug хранится в поле post_name, в Bitrix — в поле CODE элемента инфоблока. Ошибка в маппинге при переносе ломает адреса и делает старые ссылки нерабочими
SEO-поля: в WordPress метаданные страниц часто лежат в wp_postmeta (в том числе при использовании Yoast, Rank Math и аналогов), в Bitrix — в свойствах инфоблока или отдельных полях; перенос должен быть явно спроектирован
Редиректы: эффективнее и надёжнее настраивать на уровне веб-сервера (nginx или аналог), а не только средствами CMS, особенно при массовых правилах
Производительность: «голый» Bitrix без кеша и оптимизаций обычно тяжелее типового WordPress; это может отразиться на Core Web Vitals и косвенно на ранжировании

Проверка после миграции сводится к простым шагам: убедиться, что запрос к старому URL возвращает ответ 301 с заголовком Location на новый адрес, а запрос к новому URL — ответ 200. Если вместо этого вы видите 404 или 302, позиции и трафик будут падать, пока ситуация не исправлена. Имеет смысл заранее подготовить список ключевых страниц (топ по трафику и по ссылочному весу) и после переключения пройтись по нему вручную или с помощью скриптов, проверяя статус-коды и заголовки. То же касается sitemap и раздела «Покрытие» в панелях вебмастеров: расхождения между старым и новым списком URL нужно устранять сразу, а не «в следующем спринте».

Типичные ошибки при принятии решения

Чаще всего встречаются такие просчёты:

Переносят только HTML-контент, не заботясь о slug, мета-тегах и редиректах
Меняют структуру URL «чтобы стало красивее» или «логичнее», не оценивая последствия для индекса
Игнорируют категории и теги: в WordPress они живут в своей модели данных, в Bitrix их нужно явно смоделировать (разделы, Highload и т.п.)
Забывают снять запрет индексации или открыть сайт для роботов после переноса
Не проверяют robots.txt и настройки в панелях вебмастеров после переключения

Самая дорогая ошибка — считать, что SEO восстановится само собой. Не восстановится: поисковику нужны однозначные сигналы (те же URL или корректные 301), актуальный sitemap и стабильная работа сайта. Не менее опасно поручать миграцию команде, которая не различает постоянный и временный редирект или не умеет выгружать полный список URL из старой CMS: без этого любые обещания «сохранить SEO» остаются декларацией. Имеет смысл зафиксировать критерии приёмки до старта работ и привязывать этапы оплаты или релиза к их выполнению.

Моя позиция

SEO рушит не Bitrix и не WordPress. Его рушит небрежная миграция.

Если при переносе сохраняется структура URL, корректно настроены 301, перенесены метаданные и проведено тестирование на staging до выката на прод — трафик остаётся стабильным. Если хотя бы один из этих пунктов пропущен — просадка практически гарантирована.

CMS — инструмент. Структура и дисциплина — основа. Понимание этого и отличает миграцию, после которой сайт продолжает приносить трафик, от той, после которой месяцами разгребают последствия. Резюмируя: винить Bitrix или WordPress в просадке трафика после переезда — значит смотреть не туда. Смотреть нужно на то, сохранили ли вы адреса и сигналы для поисковика; если да — смена платформы остаётся прозрачной и для пользователей, и для роботов. Если нет — просадка почти неизбежна, и исправлять придётся уже по факту, с потерями во времени и в деньгах.

Read more on viku-lov.ru

WordPress: JSON-LD для CPT — дубли и ошибки

Андрей Викулов (VProger) — Mon, 23 Feb 2026 18:56:45 +0000

WordPress: JSON-LD для CPT — дубли и ошибки

Владельцы сайтов на WordPress часто ловят одну и ту же боль: добавили Custom Post Type (например, articles или news), а JSON-LD разметка либо не появляется, либо ломается синтаксисом, либо дублируется в <head>. В итоге Google Search Console/ Rich Results Test ругаются на невалидный Structured Data — и красивые сниппеты в выдаче не прилетают.

Ниже — рабочий вариант генерации BlogPosting/Article через wp_head, с безопасной сериализацией JSON (wp_json_encode) и защитой от дублей.

Сниппеты по статье:

JSON-LD класс для CPT
JSON-LD для CPT без класса
curl: проверка JSON-LD в head
Диагностика JSON-LD для CPT

В чём проблема

Реальный симптом

Вы регистрируете Custom Post Type:

register_post_type('articles', [
  'public'      => true,
  'has_archive' => true,
  // ...
]);

Но на странице /articles/my-post/ происходит одно из трёх:

В исходнике нет блока <script type="application/ld+json">…</script>
JSON ломается (в консоли/валидаторе): Unexpected token < in JSON
Разметка дублируется: 2–3 одинаковых блока в <head>

Пример из Rich Results Test:

ERROR: Missing required field "author"
ERROR: Missing required field "datePublished"
WARNING: Multiple BlogPosting detected on page

Почему это происходит

Тема не генерирует JSON-LD для CPT — часто разметка делается только для стандартного post.
SEO-плагин добавляет свою разметку — и вы “добавили ещё одну такую же”.
Неправильный хук — вставили в template_redirect/шаблон, а не в wp_head.
JSON собирается руками строкой — кавычки, спецсимволы, HTML в excerpt → привет, сломанный JSON. Нужен wp_json_encode().

Рабочее решение

Шаг 1: Класс генерации JSON-LD для CPT

Создайте файл:

wp-content/themes/your-theme/includes/class-jsonld-cpt.php

(или в небольшом плагине — логика та же).

<?php
/**
 * JSON-LD Generator for Custom Post Types
 * Place in:
 * - wp-content/themes/your-theme/includes/class-jsonld-cpt.php
 * Or:
 * - wp-content/plugins/your-plugin/includes/class-jsonld-cpt.php
 */

class JSONLD_CPT_Generator
{
    private array $target_post_types = ['articles', 'news', 'publications'];

    public function __construct()
    {
        add_action('wp_head', [$this, 'output_jsonld'], 10);
    }

    public function output_jsonld(): void
    {
        // Только single страницы нужных CPT
        if (!is_singular($this->target_post_types)) {
            return;
        }

        global $post;
        if (!$post instanceof WP_Post) {
            return;
        }

        // Защита от дублей: если уже выводили — выходим
        if (did_action('jsonld_cpt_output')) {
            return;
        }

        $jsonld = $this->build_blogposting_schema($post);
        if (!$jsonld) {
            return;
        }

        echo "\n" . '<script type="application/ld+json">' . "\n";
        echo wp_json_encode($jsonld, JSON_UNESCAPED_UNICODE | JSON_PRETTY_PRINT);
        echo "\n" . '</script>' . "\n";

        // Маркер, что мы уже вывели JSON-LD
        do_action('jsonld_cpt_output');
    }

    private function build_blogposting_schema(WP_Post $post): array
    {
        $author_id   = (int) $post->post_author;
        $author_name = get_the_author_meta('display_name', $author_id);
        $author_url  = get_author_posts_url($author_id);

        $publish_date  = get_the_date(DATE_W3C, $post);
        $modified_date = get_the_modified_date(DATE_W3C, $post);

        // Изображение: featured image или заглушка
        $image_id  = (int) get_post_thumbnail_id($post->ID);
        $image_url = $image_id
            ? wp_get_attachment_image_url($image_id, 'full')
            : (get_stylesheet_directory_uri() . '/assets/images/og-default.png');

        // Категория (первая)
        $categories = get_the_terms($post->ID, 'category');
        $section = ($categories && !is_wp_error($categories))
            ? $categories[0]->name
            : 'General';

        $schema = [
            '@context' => 'https://schema.org',
            '@type'    => 'BlogPosting',
            'mainEntityOfPage' => [
                '@type' => 'WebPage',
                '@id'   => get_permalink($post->ID),
            ],
            'headline'      => get_the_title($post->ID),
            'description'   => get_the_excerpt($post->ID),
            'image' => [
                '@type'  => 'ImageObject',
                'url'    => $image_url,
                'width'  => 1200,
                'height' => 630,
            ],
            'datePublished' => $publish_date,
            'dateModified'  => $modified_date,
            'author' => [
                '@type' => 'Person',
                'name'  => $author_name ?: get_bloginfo('name'),
                'url'   => $author_url,
            ],
            'publisher' => [
                '@type' => 'Organization',
                'name'  => get_bloginfo('name'),
                'logo'  => [
                    '@type'  => 'ImageObject',
                    'url'    => get_stylesheet_directory_uri() . '/assets/images/logo.png',
                    'width'  => 600,
                    'height' => 60,
                ],
            ],
            'articleSection' => $section,
            'wordCount'      => str_word_count(wp_strip_all_tags($post->post_content)),
        ];

        // keywords из тегов
        $tags = get_the_terms($post->ID, 'post_tag');
        if ($tags && !is_wp_error($tags)) {
            $schema['keywords'] = implode(', ', wp_list_pluck($tags, 'name'));
        }

        return $schema;
    }
}

// Инициализация
new JSONLD_CPT_Generator();

Шаг 2: Подключение в `functions.php`

<?php
// wp-content/themes/your-theme/functions.php

require_once get_stylesheet_directory() . '/includes/class-jsonld-cpt.php';

Шаг 3: Альтернатива без класса (быстро и грубо, но работает)

<?php
add_action('wp_head', 'custom_cpt_jsonld_output', 10);

function custom_cpt_jsonld_output(): void
{
    $target_types = ['articles', 'news'];

    if (!is_singular($target_types)) {
        return;
    }

    if (did_action('jsonld_cpt_output')) {
        return;
    }

    global $post;
    if (!$post instanceof WP_Post) {
        return;
    }

    $schema = [
        '@context' => 'https://schema.org',
        '@type'    => 'BlogPosting',
        'headline' => get_the_title($post->ID),
        'datePublished' => get_the_date(DATE_W3C, $post),
        'dateModified'  => get_the_modified_date(DATE_W3C, $post),
        'author' => [
            '@type' => 'Person',
            'name'  => get_the_author_meta('display_name', (int) $post->post_author),
        ],
        'publisher' => [
            '@type' => 'Organization',
            'name'  => get_bloginfo('name'),
        ],
    ];

    echo '<script type="application/ld+json">' . "\n";
    echo wp_json_encode($schema, JSON_UNESCAPED_UNICODE | JSON_PRETTY_PRINT);
    echo "\n" . '</script>' . "\n";

    do_action('jsonld_cpt_output');
}

Проверка результата

1) Проверка в исходнике

Откройте страницу CPT и найдите в <head>:

должен быть один блок <script type="application/ld+json">
внутри — валидный JSON (без HTML, без “поехавших” кавычек)

2) Быстрая проверка через `curl`

curl -s https://yoursite.com/articles/my-post/ | grep -A 60 'application/ld+json'

3) Проверка на дубли

curl -s https://yoursite.com/articles/my-post/ | grep -c 'application/ld+json'

Ожидаемо: 1

4) Google Rich Results Test

Вбейте URL в Rich Results Test и смотрите:

✅ BlogPosting/Article detected
✅ критических ошибок нет
⚠️ warnings допустимы (например, articleBody)

Типичные ошибки

❌ Ошибка 1: JSON ломается из-за кавычек в заголовке

Симптом:

Uncaught SyntaxError: Unexpected token " in JSON

Причина: JSON собирается строкой или через json_encode без нормальной сериализации.

Исправление:

// ❌ плохо
echo '{"headline":"' . get_the_title() . '"}';

// ✅ нормально
echo wp_json_encode(['headline' => get_the_title()]);

❌ Ошибка 2: Разметка дублируется

Симптом: 2–3 блока JSON-LD в <head>.

Причина: тема + SEO-плагин (Yoast/RankMath) или несколько add_action('wp_head', ...).

Исправление:

выключить structured data для CPT в SEO-плагине (если есть такая настройка),
оставить один источник разметки,
использовать маркер did_action('jsonld_cpt_output').

❌ Ошибка 3: `Missing required field "author"`

Причина: неверная структура author или он пустой.

Исправление (правильная структура):

'author' => [
  '@type' => 'Person',
  'name'  => get_the_author_meta('display_name', (int) $post->post_author),
  'url'   => get_author_posts_url((int) $post->post_author),
]

❌ Ошибка 4: JSON-LD не появляется на CPT

Причина: is_singular() проверяет не тот post type (или CPT другой).

Исправление:

$target_types = ['articles', 'news', 'publications'];

if (!is_singular($target_types)) {
  return;
}

Если не работает: чеклист

CPT реально существует:

post_type_exists('articles'); // должно вернуть true

Хук вообще вызывается (временно):

error_log('JSONLD: output called');

Кэш мешает:

очистить кэш плагина/сервера,
отключить page cache на время проверки.

Посмотреть PHP-логи:

tail -f /var/log/php/error.log

Где применять

Среда	Применимость	Примечание
Production	✅ Да	основной сценарий
Dev/Staging	✅ Да	тест перед деплоем
Docker	✅ Да	без изменений
BitrixVM	✅ Да	только проверь права на логи
Nginx/Apache	✅ Да	на генерацию не влияет
CI/CD	⚠️ Частично	удобно валидировать через CLI

Связанные материалы

Сниппеты по статье:

JSON-LD класс для CPT
JSON-LD для CPT без класса
curl: проверка JSON-LD в head
Диагностика JSON-LD для CPT

Другие сниппеты и справочник:

CLI валидатор JSON-LD
CLI валидатор микроразметки
Термин: JSON-LD
Термин: Schema.org

Итоги

Если JSON-LD для CPT в WordPress не появляется, ломается или дублируется, почти всегда виноваты: неправильный хук, ручная сборка JSON и конфликт с SEO-плагином. Решение простое и скучное (значит хорошее): wp_head + wp_json_encode() + маркер от дублей через did_action().

Read more on viku-lov.ru

Как включить GeoIP в Nginx: переменные для логов и заголовков

Андрей Викулов (VProger) — Mon, 23 Feb 2026 18:53:18 +0000

Как включить GeoIP в Nginx: переменные для логов и заголовков

Запрос «как включить GeoIP в Nginx и получить переменные для логов и заголовков» чаще всего всплывает у тех, кто ведёт аудит трафика на VPS: нужно видеть страну/город в access.log или прокинуть страну в приложение (например, Bitrix за Apache). В конце будет рабочая конфигурация для BitrixVM (nginx+httpd), проверка, и список типичных проблем.

В чём проблема

Симптом обычно один из этих:

1) В конфиг добавили geoip_country / geoip_city, а Nginx на перезагрузке падает:


nginx: [emerg] unknown directive "geoip\_country" in /etc/nginx/nginx.conf:XX

Или модуль подключили, но переменные пустые — в логах вместо страны -:


1.2.3.4 - - [16/Feb/2026:12:10:11 +0000] "GET / HTTP/2.0" 200 123 "-" "-" country=- city=-

Причины ровно две:

Модуль не загружен (динамические модули подключаются через load_module, иначе директивы неизвестны). Официальный модуль называется ngx_http_geoip_module и создаёт переменные на основе баз MaxMind. (nginx.org)
Нет базы или она не в том формате. Важно: legacy GeoLite (.dat) давно сняты с раздачи, MaxMind официально прекратил GeoLite Legacy. Поэтому старые команды с GeoIP.dat.gz по прямым ссылкам сегодня чаще мёртвые, чем живые. (MaxMind)

Ещё по современности (2025–2026): если вам нужна актуальная бесплатная геобаза, это GeoLite2 (MMDB) и по сути это уже модуль GeoIP2 (в NGINX Plus он официальный). (docs.nginx.com)

Но в BitrixVM обычно стоит open source Nginx — там штатный модуль ngx_http_geoip_module работает с legacy-форматом. Поэтому ниже — два практичных пути: (A) включить legacy GeoIP модуль с .dat, если база у вас есть (коммерческая/внутренняя), (B) если у вас NGINX Plus — включить GeoIP2 как правильный вариант на будущее.

Рабочее решение

Ниже шаги ориентированы на BitrixVM 9+ (CentOS Stream 9+, nginx + httpd). Все команды выполняются из-под root , sudo не используем.

1) Убедиться, что Nginx установлен из официального репозитория

Официальные пакеты Nginx ставятся из репозитория nginx.org. Инструкция по подключению репозитория — на сайте NGINX. (nginx.org)

Проверка:


nginx -v

rpm -qa | grep -E '^nginx'

Если Nginx не из nginx.org — дальше тоже можно жить, но пакеты модулей и путь к .so могут отличаться.

2) Установить динамический модуль GeoIP (legacy)

Пакет модуля на RHEL/CentOS-семействе обычно называется nginx-module-geoip (динамический модуль). Сам принцип — модуль ставится отдельно, затем подключается через load_module. (nginx.org)

Команды:


dnf makecache

dnf install -y nginx-module-geoip

Проверим, что файл модуля появился:


ls -la /usr/lib64/nginx/modules | grep geoip || true

Ожидаемо увидеть что-то вроде:


ngx\_http\_geoip\_module.so

3) Подготовить каталог под базы GeoIP

Создадим каталог, куда будем класть базы (как минимум country, опционально city):


mkdir -p /etc/nginx/geoip

chmod 0755 /etc/nginx/geoip

Важное примечание про базы (без розовых очков)

Официальный модуль ngx_http_geoip_module ожидает предкомпилированные базы MaxMind legacy формата. (nginx.org)
Бесплатные GeoLite Legacy базы официально прекращены (их больше не обновляют и не раздают). (MaxMind)

Что делать на практике:

Если у вас уже есть GeoIP.dat / GeoLiteCity.dat (из старых проектов, из внутреннего артефакт-хранилища, из коммерческой подписки) — кладём их в /etc/nginx/geoip/.
Если нет — не тратьте время на “магические” левые ссылки: проще и правильнее перейти на GeoIP2 (см. путь B ниже) или использовать GeoIP только для грубой аналитики через внешний сервис.

Для варианта A предполагаем, что файлы у вас есть:


пример: вы загрузили базы сами и положили в каталог

ls -la /etc/nginx/geoip

Ожидаемые имена (можно свои, главное путь правильно указать в конфиге):

/etc/nginx/geoip/GeoIP.dat
/etc/nginx/geoip/GeoLiteCity.dat

4) Подключить модуль и базы в конфиге Nginx (BitrixVM)

Где править в BitrixVM

В BitrixVM конфигурация обычно разнесена, но базовый путь стандартный:

главный файл: /etc/nginx/nginx.conf
дополнительные: /etc/nginx/conf.d/*.conf (и/или bitrix-специфичные include)

Нам важно соблюсти правило Nginx: load_module допускается только в основном контексте (верх файла, до events {} / http {}). (nginx.org)

Сделаем аккуратно: создадим отдельный файл и подключим его в nginx.conf, если у вас уже есть include для модулей. Если include нет — вставьте строку load_module прямо в начало nginx.conf.

Вариант 1 (предпочтительно): отдельный файл

Создаём /etc/nginx/conf.d/00-geoip-load.conf (если у вас conf.d инклюдится в main-контексте — это редкость). В большинстве схем conf.d подключается внутри http {}, поэтому этот вариант может не сработать.

Вариант 2 (надёжно): правим /etc/nginx/nginx.conf

Открываем /etc/nginx/nginx.conf и добавляем в самое начало:


load\_module "/usr/lib64/nginx/modules/ngx\_http\_geoip\_module.so";

Дальше — внутри http {} добавляем пути к базам:


http {

geoip\_country /etc/nginx/geoip/GeoIP.dat;

geoip\_city /etc/nginx/geoip/GeoLiteCity.dat;

...

}

Это включает переменные $geoip_country_code, $geoip_country_name и пачку city-переменных. Список переменных и назначение описаны в документации модуля. (nginx.org)

5) Добавить GeoIP в access.log и прокинуть заголовки к Apache/приложению

5.1. Логирование (быстро увидеть пользу)

В http {} определим формат лога, где будут страна/город:


log\_format main\_geoip '$remote\_addr - $remote\_user [$time\_local] '

'"$request" $status $body\_bytes\_sent '

'"$http\_referer" "$http\_user\_agent" '

'country=$geoip\_country\_code country\_name="$geoip\_country\_name" '

'city="$geoip\_city" lat=$geoip\_latitude lon=$geoip\_longitude';

И используем его для access.log:


access\_log /var/log/nginx/access.log main\_geoip;

Если у вас уже задан свой log_format в BitrixVM — не ломайте чужое. Добавьте новый main_geoip и подключите его точечно на нужном server {} через access_log ... main_geoip;.

5.2. Заголовки в апстрим (nginx -> httpd -> Bitrix)

Если Nginx проксирует в Apache (типично для BitrixVM), вы можете прокинуть страну/город в бекенд заголовками. В вашем server {} или location ~ .php$ (где стоит proxy_pass или upstream на httpd) добавьте:


proxy\_set\_header X-GeoIP-Country $geoip\_country\_code;

proxy\_set\_header X-GeoIP-Country-Name $geoip\_country\_name;

proxy\_set\_header X-GeoIP-City $geoip\_city;

Так приложение сможет читать это из $_SERVER['HTTP_X_GEOIP_COUNTRY'] и т.д.

6) Если перед Nginx есть прокси/балансировщик: geoip_proxy

Если Nginx стоит не “на краю”, а за прокси (Cloudflare, ELB, внешний балансировщик), GeoIP будет смотреть на IP прокси, а не клиента. Для этого модуль поддерживает geoip_proxy и geoip_proxy_recursive и учитывает X-Forwarded-For. (nginx.org)

Пример в http {}:


geoip\_proxy 10.0.16.0/26;

geoip\_proxy\_recursive on;

Диапазон подставьте свой (подсеть балансировщика/прокси).

Проверка результата

Проверяем синтаксис конфига:


nginx -t

Ожидаемо:


syntax is ok

test is successful

Перезагружаем:


systemctl reload nginx

Дёргаем сайт и смотрим лог:


curl -I https://your-domain.tld/ | head

tail -n 5 /var/log/nginx/access.log

В конце строки лога должны появиться country=XX и другие поля. Если видите country=- — значит модуль жив, но база не отрабатывает (см. типичные ошибки ниже).

Типичные ошибки

❌ 1) unknown directive "geoip_country"

Причина: модуль не загружен через load_module или установлен не тот пакет.

Как исправить:

убедитесь, что модуль установлен: dnf install -y nginx-module-geoip
проверьте наличие файла: ls /usr/lib64/nginx/modules/ngx_http_geoip_module.so
проверьте, что load_module стоит в самом верху /etc/nginx/nginx.conf (до http {}), иначе Nginx его просто не увидит. (nginx.org)

❌ 2) Nginx стартует, но GeoIP-переменные пустые

Причина: база отсутствует/не читается/не legacy формата. Legacy GeoLite официально прекращены — это частая ловушка у инструкций “из 2016”. (MaxMind)

Как исправить:

проверьте файлы: ls -la /etc/nginx/geoip
проверьте права (Nginx должен читать): chmod 0644 /etc/nginx/geoip/*.dat
если базы нет — планируйте переход на GeoLite2 + GeoIP2 модуль (см. ниже, путь B). (docs.nginx.com)

❌ 3) Хотите “закрыть страны” и тянет написать if

Причина: в Nginx if — не как в языках программирования. Есть известная рекомендация избегать сложных if-конструкций, и использовать map. При этом даже NGINX-экосистема признаёт, что безопасные случаи есть (обычно return/rewrite). (nginx.org)

Как исправить (без фанатизма):

для маршрутизации/флагов используйте map (переменная вычисляется один раз и дальше используется в логике)
если всё-таки нужен if, ограничьте его до “проверка → return”, без set, без вложенных rewrite-цепочек (иначе потом сложно отлаживать). (nginx.org)

Где применять

Prod на VPS (BitrixVM 9+, CentOS 9+): добавить страну/город в логи, передавать в приложение, включать доп. метрики в мониторинг.
Docker : удобно, если Nginx на периметре контейнеров и вам нужно логировать географию запросов (но с базами там отдельная история).
CI/CD : можно проверять nginx -t и деплоить конфиги автоматически, чтобы GeoIP не ронял nginx на бою.
Связка nginx + httpd : прокидывайте X-GeoIP-* заголовки в Apache и дальше в Bitrix, чтобы не городить логику в PHP.

Сниппеты по статье: Nginx GeoIP: load_module и базы .dat · log_format и заголовки X-GeoIP · geoip_proxy за прокси/балансировщиком · Проверка модуля и баз (bash)

Внутренние ссылки по теме (чтобы собрать цепочку на сайте):

Путь B (коротко, но честно): GeoIP2 вместо legacy в 2025–2026

Если ваша цель — актуальная бесплатная геобаза, то правильная база — GeoLite2 (MMDB), а правильный модуль — GeoIP2. В документации NGINX Plus GeoIP2 модуль описан как официальный динамический модуль. (docs.nginx.com)

Legacy GeoIP/GeoLite в виде .dat в 2025–2026 — это в основном “наследие”, которое живёт только если у вас уже есть источник баз.

Read more on viku-lov.ru

Как включить CPT в REST API WordPress: /wp/v2 отдаёт 404

Андрей Викулов (VProger) — Mon, 16 Feb 2026 19:18:50 +0000

Как включить CPT в REST API WordPress: /wp/v2 отдаёт 404

Если у вас wordpress custom post type rest api not working , почти всегда это выглядит одинаково: CPT зарегистрирован, в админке есть, а запрос GET /wp-json/wp/v2/{post_type} возвращает 404. В конце получится нормальная регистрация CPT с REST-маршрутом в wp/v2, рабочим rest_base и поддержкой редактора блоков (Gutenberg). Опираемся только на параметры register_post_type() из официальной документации. (WordPress Developer Resources)

Сниппеты по статье: CPT с REST в теме (functions.php) · CPT с REST в mu-plugin · Диагностика CPT и REST (get_post_type_object) · curl: проверка types и endpoint

В чём проблема

Симптом

CPT виден в админке (меню, список записей есть).
В REST API endpoint отсутствует:


curl -i https://example.com/wp-json/wp/v2/items

Ожидаемо при проблеме:


HTTP/2 404

{"code":"rest\_no\_route","message":"No route was found matching the URL and request method.","data":{"status":404}}

Почему так происходит

WordPress создаёт REST-маршруты для типа записи только если при регистрации CPT указано:

show_in_rest => true

Это прямо описано в официальной документации REST API (раздел про добавление поддержки REST для кастомных типов). (WordPress Developer Resources)

Параметры rest_base и rest_controller_class — тоже часть register_post_type() и управляют URL и контроллером маршрутов. (WordPress Developer Resources)

По умолчанию show_in_rest в WordPress установлен в false: так не все типы записей автоматически попадают в API, что сохраняет обратную совместимость и снижает риск случайного раскрытия данных. Для CPT, который должен быть доступен через REST (и в редакторе блоков), параметр нужно явно включить.

Полезные первоисточники:

register_post_type() — полный список аргументов: https://developer.wordpress.org/reference/functions/register_post_type/ (WordPress Developer Resources)
REST API: поддержка кастомных типов: https://developer.wordpress.org/rest-api/extending-the-rest-api/adding-rest-api-support-for-custom-content-types/ (WordPress Developer Resources)
Справочник с примерами (допустимый вторичный источник): wp-kama.ru: register_post_type (WordPress at Your Fingertips)

Рабочее решение

Ниже — минимальный «боевой» вариант, который:

добавит маршрут в wp/v2,
задаст человеко-понятный endpoint (rest_base),
использует стандартный контроллер WordPress,
включит Gutenberg (через show_in_rest + supports => editor).

Код ниже рассчитан на PHP 8.1+ и использует declare(strict_types=1) в соответствии с современной практикой (PSR, строгая типизация). Контроллер WP_REST_Posts_Controller::class — стандартный класс ядра WordPress, менять его не требуется. Оба варианта используют только API ядра и не требуют сторонних плагинов.

Вариант 1: в теме (быстро, но не идеально для поддержки)

Готовый вариант с пояснениями: сниппет «CPT с REST API в теме».

Путь: wp-content/themes/your-theme/functions.php


<?php

declare(strict\_types=1);

add\_action('init', static function (): void {

$labels = [

'name' => \_\_('Items', 'your-textdomain'),

'singular\_name' => \_\_('Item', 'your-textdomain'),

];

register\_post\_type('item', [

'labels' => $labels,

'public' => true,

'has\_archive' => true,

// Gutenberg и REST

'show\_in\_rest' => true,

'rest\_base' => 'items',

'rest\_controller\_class' => WP\_REST\_Posts\_Controller::class,

// Чтобы редактор блоков был доступен

'supports' => ['title', 'editor', 'excerpt', 'thumbnail'],

]);

});

Аргументы show_in_rest, rest_base, rest_controller_class официально поддерживаются register_post_type(). (WordPress Developer Resources)

Вариант 2: mu-plugin (лучше для prod)

Тема может меняться, а CPT — обычно часть модели данных. Поэтому для продакшена чаще кладут в mu-plugin. Готовый код: сниппет «CPT с REST API в mu-plugin».

Путь: wp-content/mu-plugins/cpt-item.php

(если папки mu-plugins нет — создайте)


<?php

/\*\*

- Plugin Name: MU: Item CPT (REST enabled)

\*/

declare(strict\_types=1);

add\_action('init', static function (): void {

register\_post\_type('item', [

'label' => 'Items',

'public' => true,

'show\_in\_rest' => true,

'rest\_base' => 'items',

'rest\_controller\_class' => WP\_REST\_Posts\_Controller::class,

'supports' => ['title', 'editor'],

]);

}, 10);

Диагностика: убедиться, что WordPress реально зарегистрировал REST

Посмотреть список типов в REST (сниппет «curl: проверка types и endpoint»):


curl -s https://example.com/wp-json/wp/v2/types | head

Найти свой тип и проверить rest_base / show_in_rest. Удобно через небольшой debug-код (временно). Готовый mu-plugin: сниппет «Диагностика CPT и REST».

Путь: wp-content/mu-plugins/_debug-cpt.php


<?php

declare(strict\_types=1);

add\_action('init', static function (): void {

$obj = get\_post\_type\_object('item');

if (!$obj) {

error\_log('CPT item: NOT registered');

return;

}

error\_log('CPT item: show\_in\_rest=' . (int) $obj->show\_in\_rest);

error\_log('CPT item: rest\_base=' . (string) $obj->rest\_base);

error\_log('CPT item: rest\_controller\_class=' . (string) $obj->rest\_controller\_class);

}, 999);

Если show_in_rest=0, маршрута в wp/v2 не будет — это норма по логике WordPress REST API. (WordPress Developer Resources)

Проверка результата

Проверка endpoint

После деплоя кода выполните запрос к вашему домену (подставьте свой URL вместо example.com), например:


curl -i https://example.com/wp-json/wp/v2/items

Ожидаем:

HTTP 200
JSON-массив записей (или пустой массив [], если пока нет элементов)

В ответе должны быть поля в формате REST API WordPress: id, date, slug, title, content, excerpt и т.д. — в зависимости от того, что поддерживает ваш CPT. Если приходит 404, снова проверьте rest_base и наличие типа в /wp-json/wp/v2/types.

Проверка, что маршрут существует

Если вы не уверены, что именно создаётся, откройте в браузере:

https://example.com/wp-json/ — индекс API
https://example.com/wp-json/wp/v2/types — типы, которые «видны» REST API (WordPress Developer Resources)

Проверка Gutenberg

Если CPT поддерживает editor и включён show_in_rest, то редактор блоков для него доступен: это стандартное требование редактора, так как он получает и сохраняет данные через REST API. Связь параметра show_in_rest и работы Block Editor описана в официальной документации. (Block Editor Handbook)

Типичные ошибки

1) ❌ show_in_rest => true добавили, но всё равно 404

Причина: код регистрации не выполняется (не тот файл, условие, порядок хуков, фатал до init).

Как исправить:

перенесите регистрацию в mu-plugins (самый надёжный вариант),
убедитесь, что CPT регистрируется на init,
временно залогируйте get_post_type_object() как в диагностике выше.

Официально REST-маршрут появляется только при show_in_rest=true. (WordPress Developer Resources)

2) ❌ Endpoint другой, чем вы ожидаете

Причина: вы обращаетесь к /wp/v2/item, а rest_base не задан или задан иначе.

Как исправить:

либо используйте дефолт (обычно равен имени пост-типа),
либо явно задайте rest_base => 'items' и обращайтесь к /wp-json/wp/v2/items. (WordPress Developer Resources)

3) ❌ REST работает, но Gutenberg не появляется (или падает)

Причина: CPT не поддерживает нужные фичи (supports) или отключён UI/редактор.

Как исправить:

минимум: supports => ['title', 'editor']
проверьте, что show_ui не отключён, и CPT публичный/управляемый.

supports — часть аргументов register_post_type() и напрямую влияет на доступность редактора. (WordPress Developer Resources)

4) ❌ REST отдаёт 401/403 вместо 404

Причина: это уже не про маршрут, а про права/авторизацию или фильтры безопасности (rest_authentication_errors, плагины, WAF).

Как исправить (быстрый чек):

проверьте запрос без авторизации на публичное чтение,
временно отключите плагины безопасности,
проверьте логи PHP/nginx и наличие кастомных фильтров на REST.

5) ❌ После смены кода маршрут по-прежнему не появляется

Причина: кэш объекта типов записей или необходимость сброса постоянных ссылок. В некоторых конфигурациях WordPress кэширует список типов при первом обращении к REST.

Как исправить: откройте в админке «Настройки → Постоянные ссылки» и нажмите «Сохранить» без изменений — это пересоздаёт правила. Убедитесь, что регистрация CPT выполняется на хуке init и ничто не отключает REST API для типа записи позже (фильтры rest_prepare_*, register_rest_route и т.п.).

Где применять

prod / dev: решение одинаково применимо в обеих средах. В продакшене обязательно выносите CPT в mu-plugins или отдельный плагин, чтобы смена темы не ломала REST API. В разработке удобно держать регистрацию в теме для быстрых правок.
nginx / Apache: поведение REST API от веб-сервера не зависит — важно лишь корректно проксировать запросы к PHP (например, try_files в nginx не должен перехватывать /wp-json/*).
docker / CI/CD: удобно проверять наличие маршрута curl-ом после деплоя (smoke-тест): curl -f https://site/wp-json/wp/v2/items.
BitrixVM тут ни при чём , но подход тот же: конфиг должен быть повторяемым и не зависеть от «ручных правок в теме».

Сниппеты

Практичные фрагменты по теме статьи (официальные источники: developer.wordpress.org, wp-kama.ru):

CPT с REST API в теме (functions.php) — минимальная регистрация с show_in_rest, rest_base, WP_REST_Posts_Controller для вставки в тему.
CPT с REST API в mu-plugin — тот же вариант для wp-content/mu-plugins; не зависит от темы, подходит для prod.
Диагностика CPT и REST (get_post_type_object) — временный mu-plugin: логирование show_in_rest, rest_base, rest_controller_class в debug.log для поиска причины 404.
curl: проверка types и endpoint — команды для проверки /wp-json/wp/v2/types и запроса к endpoint кастомного типа (HTTP-код и тело ответа).

Read more on viku-lov.ru

Bitrix — проблема или просто инструмент?

Андрей Викулов (VProger) — Mon, 16 Feb 2026 19:18:31 +0000

Bitrix — проблема или просто инструмент?

Коротко: Bitrix — это не проблема; проблема возникает, когда его используют без архитектуры, понимания нагрузки и ограничений платформы. Ниже — полный разбор с контекстом, кейсом и границами применимости.

С Bitrix я работаю пять лет, в веб-разработке в целом — семь. За это время внедрял, поддерживал, оптимизировал и реанимировал проекты разного масштаба: от корпоративных сайтов до B2B-платформ с интеграцией 1С, сложной бизнес-логикой и большим каталогом. Видел две крайности.

Одни проекты работают стабильно, держат нагрузку, масштабируются и не создают постоянной боли.

Другие — тормозят, падают, требуют «магии» при каждом релизе и вызывают раздражение у всей команды.

И почти всегда причина не в CMS.

В чём спор

Bitrix часто обсуждают в эмоциональном ключе. Типичные утверждения:

«Bitrix тормозит»
«Это легаси»
«На Laravel будет быстрее»
«WordPress проще и легче»
«Bitrix — сам по себе проблема»

Звучит уверенно. Но почти никогда к таким заявлениям не прикладывают ни разбор запросов, ни цифры.

Редко когда в обсуждении фигурируют:

реальные SQL-запросы и план выполнения
профилирование
нагрузочное тестирование
конфигурация сервера
настройки кеширования

Без этого разговор сводится к вкусовщине.

Контекст: где Bitrix вообще уместен

Bitrix — не универсальное решение.

Он исторически заточен под:

интеграции с 1С
коммерческие проекты в РФ и СНГ
сложные каталоги
B2B-кабинеты
многоуровневые роли доступа
тяжёлую административную логику

Если нужен лендинг или MVP за минимальный бюджет — Bitrix будет избыточен.

Если нужна сложная экосистема с бухгалтерией, интеграцией, складом и управлением доступами — там он как раз раскрывается.

Всё упирается в контекст задачи.

Что на самом деле тормозит

За годы работы почти не попадалось проектов, где «ядро Bitrix» было корнем всех бед.

Зато регулярно встречалось вот что:

отключённый композитный кеш
выборки из инфоблоков без ограничений
N+1 в ORM
50 запросов там, где должно быть 5
копипасту компонентов
перегруженные инфоблоки
неограниченные HL-блоки
сервер с дефолтной конфигурацией
отсутствие opcache
отсутствие FastCGI cache
php-fpm с одним воркером

После чего звучит: «Bitrix тормозит».

Тормозит не Bitrix — тормозит то, как его реализовали и на чём запустили.

Конкретный пример из практики

Один из проектов: крупный каталог, B2B-кабинет, интеграция с 1С. Жалобы были стандартные: «Bitrix тормозит», «нужно переписывать». Разобрались за несколько дней без смены CMS.

Симптомы были такие:

TTFB 1.8–2.3 секунды
периодические 502
рост CPU до 100%
админка «задумывается» на 5–7 секунд

Сделали по шагам:

включили композитный кеш
переписали выборки без N+1
вынесли тяжёлые расчёты в фон
включили opcache
настроили php-fpm пул
добавили FastCGI cache для анонимных
оптимизировали nginx

Итог:

TTFB стабильно ниже 300 мс
нагрузка на CPU снизилась в разы
502 исчезли
админка стала отзывчивой

CMS не меняли — сменили подход к архитектуре и настройке окружения.

Когда Bitrix действительно работает

Bitrix работает нормально, если есть внятная архитектура, понимание модели данных (инфоблоки, HL, связи), кеш используется осознанно, запросы контролируются (нет N+1 и выборок «всего подряд»), сервер настроен под нагрузку и есть кто-то с опытом — хотя бы один senior или архитектор, который может указать на узкие места.

Bitrix — тяжёлая система. Тяжёлая не значит плохая: тяжёлый инструмент просто требует грамотного применения.

Серверная сторона: о чём забывают чаще всего

Многие оценивают CMS по ощущениям, не глядя на инфраструктуру: один и тот же Bitrix на дефолтном shared-хостинге и на настроенном VPS ведёт себя по-разному.

Типичный прод выглядит так:

VPS с минимальными ресурсами
дефолтный nginx
opcache выключен
php-fpm без настройки
нет мониторинга
нет профилирования

И платформу объявляют виноватой.

Грамотная конфигурация:

opcache включён
адекватные php-fpm процессы
настроенный nginx
FastCGI cache
контроль SQL
мониторинг нагрузки
логирование

Bitrix в нормальной инфраструктуре ведёт себя иначе.

Когда я бы не стал использовать Bitrix

Если по делу: я не буду рекомендовать Bitrix:

для простого лендинга
для микро-проекта
для MVP стартапа
если нет команды с опытом
если нет бюджета на инфраструктуру
если нет архитектурного контроля

В таких случаях проще взять более лёгкий стек: тот же WordPress, Laravel или даже статику с формами. Проблема начинается, когда Bitrix выбирают «по привычке» или «как у всех», без анализа задачи, команды и бюджета на поддержку.

Технический аспект без эмоций

По пунктам:

Производительность

Зависит от кеширования, структуры данных, качества SQL, нагрузки и сервера. Не от названия CMS: «Bitrix» или «Laravel» сами по себе не быстрые и не медленные — бывает быстрая или медленная реализация и окружение.

Масштабируемость

Bitrix масштабируется, если данные структурированы, кеш продуман, а архитектура не превратилась в хаотичную доработку. Как и любая тяжёлая CMS, он требует дисциплины: без неё любой стек рано или поздно упирается в потолок.

Поддержка

Да, Bitrix сложнее, чем WordPress: больше сущностей, своя документация, обновления ядра и модулей. Но в крупных проектах он даёт строгую бизнес-логику, внятный контроль ролей и возможность держать архитектуру в рамках, а не в виде россыпи скриптов.

DevOps-сложность

Выше, чем у простого LAMP. Это плата за гибкость, интеграции и объём встроенного функционала: окружение нужно настраивать осознанно, а не «из коробки».

Почему возникает репутация «проблемной CMS»

Основные причины:

Проекты делают без внятной архитектуры.
Крутят на минимальном хостинге и удивляются лагам.
Копируют чужие решения, не разбираясь в последствиях.
Не проводят профилирование и не смотрят тяжёлые запросы.
Не считают нагрузку до запуска в прод.
Экономят на опытном разработчике или архитекторе.

В большинстве плохих кейсов виноват не «плохой Bitrix», а отсутствие нормального инженерного подхода.

Типичные ошибки при принятии решения

Сводятся к одному: выбор и эксплуатация без анализа.

Выбирают по привычке — «у нас всегда был Bitrix» или «заказчик просит» — без оценки задачи и команды.
Копируют чужую архитектуру — взяли конфиг с другого проекта, не подогнали под нагрузку и модель данных.
Не закладывают время на настройку окружения — считают, что «поставили и поехало», без opcache, кеша и мониторинга.
Не думают о поддержке через год-два — кто будет разбираться в кастомных доработках и обновлениях.

Исправлять такое уже в проде дороже, чем сразу заложить нормальный старт и окружение. Поэтому перед выбором стека имеет смысл честно оценить задачу, команду и бюджет на инфраструктуру. Границу применимости инструмента лучше понимать до старта проекта, а не после первых жалоб на производительность и срочных фиксов в проде.

Главное заблуждение

«Если сменить CMS, всё станет быстрее».

Иногда смена стека действительно помогает — когда задача не подходит под текущий инструмент. Но чаще проблемы мигрируют вместе с проектом: архитектура остаётся рыхлой, нагрузку по-прежнему не считают, сервер не настраивают. В итоге новая система через полгода начинает «тормозить» так же, и винят уже её. Корень не в названии CMS, а в процессе принятия решений и в уровне эксплуатации.

Моя позиция

Bitrix — инструмент. Плохим или хорошим его не назовёшь: он просто требовательный к рукам и к окружению.

Без понимания архитектуры, кеширования и нагрузки он будет выглядеть проблемой. При грамотном использовании решает задачи, которые на других CMS тянут за собой кучу кастомной разработки.

Проблема не в платформе, а в том, как команда подходит к инженерии. Речь уже не про CMS, а про уровень команды. Если такой разбор без маркетинговой шелухи полезен — в блоге есть и пошаговые инструкции по Bitrix, и другие экспертные тексты.

Read more on viku-lov.ru

WordPress: ACF поле не сохраняется — чиним запись meta

Андрей Викулов (VProger) — Sun, 15 Feb 2026 07:45:22 +0000

WordPress: ACF поле не сохраняется — чиним запись meta

Запрос acf поле не сохраняется wordpress обычно прилетает так: ACF-поля в админке есть, вводишь значение, жмёшь «Обновить», а потом пусто — и get_field() возвращает null или пустую строку. В конце этой инструкции: meta реально пишется в wp_postmeta, get_field() стабильно отдаёт значение, а конфликты с хуками перестают устраивать тихий саботаж.

Сниппеты по статье: ACF Save Debug (MU-plugin) · ACF save_post с проверкой autosave/revision · WP-CLI: проверка post meta для ACF · ACF update_value: нормализация значения

В чём проблема

Симптомы:

ACF-поля отображаются в админке.
После сохранения значение пропадает.
В базе в wp_postmeta ключа либо нет, либо он не меняется.
get_field('my_field', $post_id) возвращает пусто.

Самая частая причина на проде: конфликт хуков сохранения.

ACF сохраняет значения при acf/save_post.
Ваши (или чужие) функции на save_post/wp_insert_post/pre_post_update могут:
срабатывать на autosave или revision и перетирать meta;
делать wp_update_post() внутри save_post и запускать каскад «сохранился → пересохранился → перезатёрлось»;
вызывать update_field()/update_post_meta() в неправильный момент (до/вместо ACF-сейва);
чистить $_POST (да, такое тоже бывает — “безопасность” уровня «удалить данные»).

Почему autosave/revision важны: WordPress создаёт автосохранения и ревизии, и если ваш хук не фильтрует их, он сработает «не на тот пост» и/или перезапишет meta “пустым”. Для проверки есть wp_is_post_autosave() и wp_is_post_revision().

Типичный сценарий на проде: в логе нет ошибок PHP, в админке всё сохраняется “без жалоб”, но на фронте или в REST API поле пустое. Часто виноват не сам ACF, а код темы или плагина на save_post с приоритетом 10: он срабатывает в своём порядке и перезаписывает meta до или после ACF. Ещё вариант — объектный кеш (Redis/Memcached): старые значения meta кешируются, и даже при корректной записи в БД ты видишь пустое значение, пока кеш не сбросится.

Рабочее решение

Ниже — рабочий, «боевой» путь: сначала диагностируем , потом переносим вашу логику на правильный хук ACF и выключаем перезапись на autosave/revision.

1) Включаем логирование на prod без плясок

Файл: wp-config.php


define('WP\_DEBUG', true);

define('WP\_DEBUG\_LOG', true);

define('WP\_DEBUG\_DISPLAY', false);

Дальше хватаем лог:


tail -f wp-content/debug.log

Если у тебя Nginx + PHP-FPM — параллельно полезно смотреть error.log PHP-FPM / nginx, но debug.log обычно хватает. После правок не забудь перезагрузить PHP (или сервис PHP-FPM), иначе старый описанный конфиг не подхватится.

2) Быстрая проверка: ACF вообще отправляет данные?

Сделаем mu-plugin (так надёжнее: не отключится вместе с темой). Готовый вариант с пояснениями: сниппет «ACF Save Debug (MU-plugin)».

Файл: wp-content/mu-plugins/acf-save-debug.php

(если папки нет — создай)


<?php

/\*\*

- Plugin Name: ACF Save Debug (MU)

\*/

add\_action('acf/save\_post', function ($post\_id) {

// Логируем только админку и только реальные посты

if (!is\_admin()) return;

// ACF сохраняет значения из $\_POST['acf'] (с версии 5+).

$keys = isset($\_POST['acf']) && is\_array($\_POST['acf']) ? array\_keys($\_POST['acf']) : [];

error\_log('[ACF] acf/save\_post post\_id=' . $post\_id . ' keys=' . implode(',', $keys));

}, 1);

Что это даёт:

Если в логе keys пустой — ACF не получает значения (не тот экран, не тот post_id, поля disabled/readonly, конфликт JS/редактора, кастомная форма без acf_form_head() и т.д.).
Если keys есть , но meta не меняется — конфликт записи/перезапись ниже по цепочке.

Сохрани пост с заполненным ACF-полем и сразу открой debug.log: должна появиться строка с нужным post_id и списком ключей из $_POST['acf']. Если ключей нет — проблема на этапе отправки формы (фронт или другой плагин режет данные).

3) Проверяем, пишется ли meta в базу (WP-CLI)

Команды и порядок проверки: сниппет «WP-CLI: проверка post meta для ACF». Сначала узнаём post_id и имя поля (name). Дальше:


wp post meta list 123 --format=table

wp post meta get 123 my\_field

WP-CLI команды по meta — официальные, стабильные.

Если поле ACF не в my_field, а хранится иначе (например, field_XXXXXXXX как reference) — ты это тоже увидишь в списке. Так можно быстро убедиться, что запись в БД вообще происходит: если после сохранения в админке в wp post meta list появляется нужный ключ с актуальным значением, значит ACF и база в порядке, а проблема может быть в кеше или в месте, откуда ты читаешь поле.

4) Убираем конфликт: переносим вашу логику с save_post на acf/save_post

Если у тебя (или у темы/плагина) есть код вроде этого:


add\_action('save\_post', function ($post\_id) {

update\_post\_meta($post\_id, 'my\_field', $\_POST['something'] ?? '');

});

…то он легко убьёт ACF, потому что:

сработает на autosave/revision;
может записать пустоту раньше/позже ACF;
может триггерить пересохранение.

Правильная точка интеграции для ACF-полей — acf/save_post. Готовый MU-plugin с проверкой autosave/revision и примером update_field: сниппет «ACF save_post с проверкой autosave/revision».

Файл: wp-content/mu-plugins/acf-save-fix.php


<?php

/\*\*

- Plugin Name: ACF Save Fix (MU)

\*/

// 20 = "после того, как ACF обработал свои данные" (часто оптимально на практике)

add\_action('acf/save\_post', function ($post\_id) {

// 1) Не трогаем автосохранения и ревизии.

if (wp\_is\_post\_autosave($post\_id) || wp\_is\_post\_revision($post\_id)) {

return;

}

// 2) На всякий — работаем только в админке

if (!is\_admin()) {

return;

}

// 3) Пример: если нужно вычислить и сохранить зависимое значение в ACF поле

// (update\_field — официальный путь для записи ACF значения).

$value = get\_field('source\_field', $post\_id);

if ($value === null || $value === '') {

return;

}

$computed = mb\_strtoupper((string)$value);

update\_field('my\_field', $computed, $post\_id);

}, 20);

Ключевая идея: не мешай ACF сохраняться , а дополняй его после сейва, на acf/save_post. Приоритет 20 выбран не случайно: ACF сам вешает обработчик на acf/save_post, и к моменту срабатывания твоего кода с приоритетом 20 значения полей уже записаны в wp_postmeta. Если нужна логика “сначала ACF, потом я” — используй приоритет 20 или выше; если “сначала я, потом ACF” — приоритет меньше 10 (осторожно: не перезаписывай meta пустым).

5) Если у тебя фильтр acf/update_value — не делай там записи в БД

acf/update_value — фильтр для модификации значения перед сохранением , а не для побочных эффектов. Пример нормализации (trim, регистр) без записи в другие поля: сниппет «ACF update_value: нормализация значения».

То есть норм:


add\_filter('acf/update\_value/name=my\_field', function ($value, $post\_id, $field) {

// Нормализуем то, что сохраняем

return is\_string($value) ? trim($value) : $value;

}, 10, 3);

А вот делать update_field() внутри acf/update_value — частый путь к рекурсии/гонкам/«то пусто, то густо». Для побочных сохранений используй acf/save_post, как выше.

6) Приоритет хука и порядок выполнения

Иногда поле сохраняется “через раз” или только при втором нажатии «Обновить». Это часто связано с тем, что несколько обработчиков висят на acf/save_post или save_post с разными приоритетами и перезаписывают друг друга. Проверь все места, где вызываются update_post_meta() или update_field() для этого поста: убедись, что они либо на acf/save_post с приоритетом не меньше 15, либо явно пропускают autosave/revision. Один “грязный” хук на приоритете 5 может обнулить meta до того, как ACF успеет записать данные.

Проверка результата

1) Проверка в админке

Открой пост/страницу с ACF.
Введи тестовое значение.
Сохрани.
Перезагрузи страницу редактирования — значение должно остаться.

Если значение пропало после перезагрузки, повтори цепочку из раздела «Рабочее решение»: проверь лог на наличие ключей в acf/save_post, затем через WP-CLI убедись, что meta есть в базе. Если в БД значение есть, а в админке пусто — возможен кеш страницы или кеш объекта (Redis/Memcached).

2) Проверка через WP-CLI


wp post meta get 123 my\_field

Ожидаешь увидеть сохранённое значение.

3) Проверка чтения через PHP (на шаблоне/в плагине)


$value = get\_field('my\_field', 123);

var\_dump($value);

get_field() официально возвращает значение поля из нужной “локации” (post/user/term/options) — важно, чтобы post_id был правильный. На проде после успешной записи имеет смысл один раз сбросить объектный кеш (если используется): wp cache flush через WP-CLI или сброс в панели хостинга, чтобы не ловить старые значения из кеша.

Типичные ошибки

❌ 1) Хук save_post перезаписывает meta пустым

Причина: хук срабатывает на autosave/revision или порядок хуков перетирает ACF.

Исправление: перенеси логику на acf/save_post, добавь проверки wp_is_post_autosave()/wp_is_post_revision().

❌ 2) Неверный post_id для get_field()

Причина: поле не у поста, а у options/user/term, а ты читаешь как пост.

Исправление: передай правильный post_id (например, option, user_{$id}, term_{$id} — по модели ACF) и проверь по документации get_field().

❌ 3) “Я модифицирую значение в acf/update_value, но оно не сохраняется”

Причина: ты возвращаешь null/пустоту, либо делаешь побочные записи в БД прямо в фильтре.

Исправление: в acf/update_value только возвращай нормализованное $value. Любые доп. сохранения — в acf/save_post.

❌ 4) Поле “видно”, но $_POST['acf'] пустой

Причина: кастомная форма/метабокс, конфликт JS, поле disabled/readonly, или это вообще не ACF экран.

Исправление: смотри лог mu-plugin, проверь что ACF реально сабмитит $_POST'acf'.

❌ 5) В БД meta есть, а на фронте или в API пусто

Причина: объектный кеш (Redis, Memcached, кеш плагина) отдаёт старую версию meta; или читаешь поле в неправильном контексте (например, в цикле без передачи post_id).

Исправление: выполни wp cache flush или сброс кеша в админке; при вызове get_field() всегда передавай второй аргумент — ID поста, термина или 'option'.

❌ 6) Поле внутри группы (repeater/flexible) не сохраняется

Причина: обращаешься к полю по имени без учёта группы или подполя; при ручном update_post_meta перезаписываешь сериализованные данные группы.

Исправление: используй get_field('group_name', $post_id) и вложенные ключи для подполей; для записи — только update_field() с путём к полю (например, my_repeater_0_my_subfield или через массив по документации ACF).

Если не работает: чеклист диагностики за 10 минут

Убедись, что acf/save_post вообще срабатывает

Смотри wp-content/debug.log и строку вида [ACF] acf/save_post post_id=... keys=....

Посмотри, кто трогает meta кроме ACF

Поиск по проекту:


grep -R "save\_post" -n wp-content/themes wp-content/plugins wp-content/mu-plugins

grep -R "update\_post\_meta" -n wp-content/themes wp-content/plugins wp-content/mu-plugins

Временно отключи подозреваемый плагин/кусок темы

На проде аккуратно: сначала на staging. Но если выбора нет — выключай точечно, не “всё подряд”.

Проверь meta напрямую в БД (если есть доступ)


SELECT meta\_key, meta\_value

FROM wp\_postmeta

WHERE post\_id = 123

ORDER BY meta\_id DESC;

Проверь, что читаешь то же поле, что сохраняешь

В ACF у поля есть name и key. Для update_field() можно передавать и то, и другое — документация это допускает и это часто спасает при переименованиях.

Сбрось кеш

Если на сервере включён объектный кеш или кеш страниц, после исправления кода выполни сброс: wp cache flush, очистка кеша в панели хостинга или перезапуск Redis/Memcached. Иначе можно долго отлаживать “правильный” код, глядя на закешированный результат.

Где применять

prod — да, именно здесь чаще всего и всплывает (конфликт плагинов/хуков, кеши, кастомные сохранения). Рецепт тот же: логи, WP-CLI, перенос логики на acf/save_post и проверка приоритетов.
docker/staging — идеально, чтобы отловить “кто перетирает meta” до выката. Можно временно включить debug.log и поставить mu-plugin для логирования без риска для продакшена.
CI/CD — можно добавить быстрый smoke-тест через WP-CLI: записать meta и прочитать обратно; при падении теста сразу видно, что сохранение или чтение полей сломалось.

Сниппеты по статье: ACF Save Debug (MU-plugin) · ACF save_post с autosave/revision · WP-CLI post meta для ACF · ACF update_value: нормализация

Пара внутренних ссылок, чтобы не искать по сайту:

Read more on viku-lov.ru

WordPress: ускоряем Nginx + PHP-FPM до TTFB меньше 300 мс

Андрей Викулов (VProger) — Fri, 13 Feb 2026 22:52:00 +0000

WordPress: ускоряем Nginx + PHP-FPM до TTFB меньше 300 мс

Если wordpress долго загружается nginx php-fpm , TTFB 2–5 секунд, CPU стабильно загружен, а плагинов немного — проблема почти всегда в конфигурации PHP-FPM, OPcache и отсутствии fastcgi_cache.

После настройки:

TTFB меньше 300 мс
CPU без перегруза
OPcache реально работает
Nginx кеширует анонимный трафик

Без Docker. Обычный VPS в prod.

Сниппеты по статье: OPcache для WordPress (php.ini) · PHP-FPM pool (pm dynamic) · Nginx fastcgi_cache для WordPress · Проверка TTFB (curl)

В чём проблема

Симптомы:

Страница открывается 2–5 секунд
curl -w "%{time_starttransfer}" показывает TTFB 1.8–3.5 сек
CPU 70–100%
top показывает php-fpm в топе процессов
Кеш-плагинов нет или они не решают проблему

Проверка TTFB (сниппет: curl TTFB):


curl -o /dev/null -s -w "TTFB: %{time\_starttransfer}\n" https://example.com

Если видите:


TTFB: 2.341221

— PHP генерирует страницу каждый раз.

Nginx не кеширует.

OPcache либо отключён, либо настроен плохо.

Причины обычно такие:

OPcache выключен или память 64MB.
PHP-FPM работает с 5 процессами при 8 ядрах.
Нет fastcgi_cache.
Неправильно настроен bypass для админки.

Как отличить от других причин: если отключить все плагины (переименовать папку wp-content/plugins) и TTFB всё равно высокий — дело в стеке (Nginx/PHP-FPM/OPcache), а не в коде темы или плагинах. Если после отключения плагинов стало быстро — оптимизируйте тяжёлые плагины или кеш на уровне приложения. Здесь разбираем именно случай «плагинов немного, но стек не настроен».

WordPress сам по себе не медленный. Медленный — стек. Если после настройки появятся 502/504 — смотрите Nginx и PHP-FPM: ошибки 502, 504. Конфиг виртуальных хостов — в настройке server blocks для нескольких проектов.

Рабочее решение

1️⃣ Настраиваем OPcache (PHP 8.2)

Готовый блок с пояснениями: сниппет «OPcache для WordPress (php.ini)». Ниже — кратко.

Файл:


/etc/php/8.2/fpm/php.ini

Ищем блок OPcache и приводим к нормальному виду:


opcache.enable=1

opcache.enable\_cli=0

opcache.memory\_consumption=256

opcache.interned\_strings\_buffer=32

opcache.max\_accelerated\_files=20000

opcache.validate\_timestamps=0

opcache.revalidate\_freq=0

opcache.fast\_shutdown=1

Почему так:

256MB — минимум для продакшена
validate_timestamps=0 — без постоянной проверки файлов
20 000 файлов — WordPress + плагины легко съедают 10k+

Путь к php.ini может отличаться: на Debian/Ubuntu это обычно /etc/php/8.2/fpm/php.ini, на CentOS/Rocky — /etc/php.ini или отдельный файл в /etc/php.d/. Убедитесь, что правите именно конфиг FPM, а не CLI: php -i | grep "Loaded Configuration" покажет активный файл для CLI, для FPM смотрите конфиг пула.

Перезапуск:


systemctl restart php8.2-fpm

Проверка:


php -i | grep opcache.enable

Ожидаем:


opcache.enable => On => On

2️⃣ Настройка PHP-FPM (CPU не должен кипеть)

Полный вариант с проверкой памяти: сниппет «PHP-FPM pool (pm dynamic)». Ниже — ключевые параметры.

Файл:


/etc/php/8.2/fpm/pool.d/www.conf

Меняем pm режим:


pm = dynamic

pm.max\_children = 20

pm.start\_servers = 4

pm.min\_spare\_servers = 4

pm.max\_spare\_servers = 8

pm.max\_requests = 500

pm.max_requests — после скольких запросов воркер перезапускается; снижает риск утечек памяти в долгоживущих процессах. 500–1000 нормально для WordPress.

Как считать:

max_children ≈ RAM / 60MB
Если 2GB RAM → ~30 процессов максимум

Проверка нагрузки:


ps --no-headers -o "rss,cmd" -C php-fpm8.2 | awk '{ sum+=$1 } END { print sum/1024 " MB" }'

3️⃣ Включаем fastcgi_cache в Nginx

Это ключевой момент. Готовый конфиг с bypass для админки: сниппет «Nginx fastcgi_cache для WordPress».

Файл:


/etc/nginx/nginx.conf

Добавляем в http{}:


fastcgi\_cache\_path /var/cache/nginx levels=1:2 keys\_zone=WORDPRESS:100m inactive=60m;

fastcgi\_cache\_key "$scheme$request\_method$host$request\_uri";

Создаём директорию:


mkdir -p /var/cache/nginx

chown -R www-data:www-data /var/cache/nginx

Размер зоны keys_zone=WORDPRESS:100m — это не место на диске, а объём ключей в памяти. 100m хватает на десятки тысяч URL. Реальный кеш лежит в /var/cache/nginx; убедитесь, что на разделе достаточно места (гигабайт и больше для активного сайта). Параметр inactive=60m — удалять ключ из кеша, если к нему не обращались 60 минут.

4️⃣ Настройка server{} для WordPress

Файл сайта:


/etc/nginx/sites-available/example.com

В location ~ .php$ добавляем:


set $skip\_cache 0;

if ($request\_method = POST) {

set $skip\_cache 1;

}

if ($query\_string != "") {

set $skip\_cache 1;

}

if ($request\_uri ~\* "/wp-admin/|/xmlrpc.php|wp-login.php") {

set $skip\_cache 1;

}

if ($http\_cookie ~\* "wordpress\_logged\_in") {

set $skip\_cache 1;

}

location ~ \.php$ {

include fastcgi\_params;

fastcgi\_pass unix:/run/php/php8.2-fpm.sock;

fastcgi\_param SCRIPT\_FILENAME $document\_root$fastcgi\_script\_name;

fastcgi\_cache WORDPRESS;

fastcgi\_cache\_valid 200 60m;

fastcgi\_cache\_bypass $skip\_cache;

fastcgi\_no\_cache $skip\_cache;

add\_header X-FastCGI-Cache $upstream\_cache\_status;

}

Перезапуск:


systemctl restart nginx

Проверка результата

Проверка TTFB


curl -I https://example.com

В заголовках должно быть:


X-FastCGI-Cache: MISS

Повторный запрос:


X-FastCGI-Cache: HIT

Проверка времени:


curl -o /dev/null -s -w "TTFB: %{time\_starttransfer}\n" https://example.com

Ожидаемый результат:


TTFB: 0.112341

CPU должен упасть минимум в 2–4 раза.

Краткий чеклист:

OPcache: php -i | grep opcache.enable → On
PHP-FPM: в pool.d/www.conf стоит pm = dynamic, pm.max_children по памяти
Nginx: в ответе есть заголовок X-FastCGI-Cache, при повторном запросе — HIT
TTFB: для закешированной главной — меньше 0,3 сек (лучше 0,05–0,15)

Если хотя бы один пункт не выполняется — возвращайтесь к соответствующему шагу выше. На проде после любых изменений конфига делайте nginx -t перед systemctl reload nginx.

Если не работает

1️⃣ Нет заголовка X-FastCGI-Cache

→ location блок не применяется.

Проверь:


nginx -T | grep fastcgi\_cache

2️⃣ Всегда BYPASS

→ Cookie не даёт кешировать.

Проверь:


curl -I https://example.com | grep Set-Cookie

3️⃣ OPcache не даёт прироста

→ validate_timestamps включён.

Проверь:


php -i | grep validate\_timestamps

Должно быть 0 в проде. После деплоя кода делайте systemctl reload php8.2-fpm, чтобы OPcache подхватил новые файлы.

4️⃣ Кеш не создаётся (всегда MISS)

→ путь к кешу неверный или нет прав.

Проверь:


ls -la /var/cache/nginx

Владелец должен быть www-data (или пользователь nginx). Если директории нет — создай и выдай права, как в шаге 3 выше, затем systemctl restart nginx.

Типичные ошибки

❌ OPcache 64MB

Причина: дефолт Debian

Решение: минимум 256MB

❌ pm = ondemand

Причина: экономия памяти

Проблема: запуск процессов под нагрузкой

Решение: dynamic

❌ Кеширование админки

Причина: нет bypass

Решение: skip_cache условия

❌ Кеш не чистится при деплое

Причина: validate_timestamps=0

Решение: после деплоя:


systemctl reload php8.2-fpm

Где применять

Production VPS
Nginx + PHP-FPM
Без Docker
CI/CD с деплоем через git pull
WordPress 6.x

Если используешь Docker — логика та же, но путь к сокету другой. Основы Nginx — в Nginx: основы веб-сервера. Дальнейшая оптимизация фронта (LCP, INP, кеш) — WordPress и Core Web Vitals.

После обновления кода или темы

При opcache.validate_timestamps=0 OPcache не перечитывает файлы сам. После деплоя (git pull, загрузка обновлённой темы или плагинов) выполните:


systemctl reload php8.2-fpm

Так PHP-FPM перезапустит воркеры и подхватит новый код. При необходимости сбросьте fastcgi_cache: удалите содержимое /var/cache/nginx или перезапустите Nginx. Для инвалидации только части кеша в Nginx нужна отдельная настройка (например, purge по ключу).

Итог

Если wordpress долго загружается nginx php-fpm , проблема почти никогда не в “тяжёлом WordPress”.

Проблема в:

выключенном OPcache
неправильном pm
отсутствии fastcgi_cache

После этих трёх шагов:

TTFB меньше 300 мс
CPU стабилен
Сайт ощущается быстрым

WordPress может работать быстро. Просто стек должен быть настроен как прод, а не как shared-хостинг 2012 года. Следуйте шагам по порядку и проверяйте результат после каждого этапа.

Read more on viku-lov.ru

WordPress: как настроить системный cron вместо WP-Cron

Андрей Викулов (VProger) — Fri, 13 Feb 2026 22:51:40 +0000

WordPress: как настроить системный cron вместо WP-Cron

Если у вас wordpress wp cron не выполняется , не отправляются письма, не работает импорт, не публикуются отложенные записи — вы упёрлись в архитектурное ограничение WP-Cron.

В продакшене на VPS с nginx это лечится правильно: отключаем псевдо-cron WordPress и переводим задачи на системный cron Linux.

В конце получите:

✔ WP-Cron отключён

✔ системный cron настроен

✔ задачи выполняются стабильно и предсказуемо

Сниппеты по статье: Отключение WP-Cron (wp-config) · Crontab для wp-cron.php · Проверка событий (wp cron event list) · Вызов wp-cron по HTTP (curl)

В чём проблема

Реальный симптом

Заказы WooCommerce не обрабатываются
wp_mail() не отправляет письма
Отложенные посты зависают
Импорт через wp_schedule_event не запускается

Почему это происходит

WP-Cron — это не настоящий cron.

Он запускается только при HTTP-запросе к сайту.

Механика (по документации WordPress):

При загрузке страницы WordPress проверяет опцию cron.
Если есть просроченные задачи — выполняет wp-cron.php.
Если трафика нет — задачи не выполняются.

На проде это приводит к:

задержкам
гонкам процессов
зависанию задач при высокой нагрузке
полному отсутствию выполнения на малопосещаемых сайтах

Как проверить, что WP-Cron не работает

Проверяем запланированные события:


wp cron event list

Если видите старые timestamps — задачи не выполняются.

Проверяем вручную:


curl https://example.com/wp-cron.php?doing\_wp\_cron

Если ничего не происходит — cron завис.

Проверяем опцию:


wp option get cron

Если там старые даты — всё очевидно.

Рабочее решение

Шаг 1. Отключаем WP-Cron

Готовый фрагмент и пояснения: сниппет «Отключение WP-Cron в wp-config». Ниже — кратко.

Файл:


/var/www/site/public\_html/wp-config.php

Добавляем строку:


define('DISABLE\_WP\_CRON', true);

Это официально рекомендуемый способ (WordPress documentation).

Важно:

Добавлять до строки


/ _That's all, stop editing!_ /

Шаг 2. Проверяем путь к PHP

На VPS:


which php

Обычно:


/usr/bin/php

Если используется PHP-FPM 8.x, путь может быть:


/usr/bin/php8.2

Шаг 3. Настраиваем системный cron

Полная строка и варианты расписания: сниппет «Crontab для wp-cron.php». Ниже — базовая настройка.

Открываем cron текущего пользователя:


crontab -e

Добавляем строку:


_/5_ \* /usr/bin/php /var/www/site/public\_html/wp-cron.php > /dev/null 2>&1

Разбор:

*/5 — каждые 5 минут
полный путь к php
полный путь к wp-cron.php
вывод в null (без мусора в почту)

Если сайт крупный — можно поставить раз в минуту:


- /usr/bin/php /var/www/site/public\_html/wp-cron.php > /dev/null 2>&1

Альтернатива через HTTP (если нет CLI PHP)

Сниппет «Вызов wp-cron по HTTP (curl)»:


_/5_ \* curl -s https://example.com/wp-cron.php?doing\_wp\_cron > /dev/null 2>&1

Но CLI-вариант надёжнее.

Шаг 4. Проверяем, что cron добавился


crontab -l

Должна быть ваша строка.

Проверка результата

Проверка выполнения задач

Через 5–10 минут (сниппет «Проверка событий wp cron event list»):


wp cron event list

Временные метки должны обновляться.

Проверка логов nginx

Файл:


/var/log/nginx/access.log

Если используете HTTP-вариант — должны появляться обращения к wp-cron.php.

Принудительный запуск


wp cron event run --due-now

Если выполняется без ошибок — система рабочая.

Диагностика, если не работает

Проверяем пользователя cron


ps aux | grep cron

Если cron работает от root, а сайт принадлежит www-data — могут быть проблемы с правами.

Лучше добавить cron от того же пользователя, под которым работает сайт.

Проверяем права доступа


ls -la wp-cron.php

Файл должен быть читаемым для пользователя cron.

Проверяем SELinux (если включён)

На CentOS:


getenforce

Если Enforcing — временно проверить:


setenforce 0

Если после этого заработало — проблема в политике.

Типичные ошибки

❌ Оставили WP-Cron включённым

Причина: забыли добавить DISABLE_WP_CRON.

Результат: двойной запуск задач.

Исправление: проверить wp-config.php.

❌ Указан неверный путь к PHP

Причина: в системе несколько версий.

Проверка:


php -v

which php

Исправление: указать полный корректный путь.

❌ Неверный путь к wp-cron.php

Причина: указали относительный путь.

Нужно:


/var/www/site/public\_html/wp-cron.php

❌ Cron добавлен, но не выполняется

Проверить:


systemctl status cron

или


systemctl status crond

Если не запущен:


systemctl start cron

Где применять

✔ Production VPS
✔ Nginx
✔ WooCommerce
✔ Импортёры
✔ Интеграции
✔ CI/CD деплой после миграции

Не применять:

Локальная разработка
Docker-контейнер без supervisor
Shared hosting без доступа к cron

Когда это критично

Малый трафик
Email-воронки
Платежи
REST-интеграции
Webhook-обработчики

Если wp cron не выполняется — это не баг WordPress.

Это неправильная эксплуатация.

Дополнительные материалы

Итог

Если wordpress wp cron не выполняется , не надо искать плагины-костыли.

Правильный прод-подход:

Отключить WP-Cron
Настроить системный cron
Проверить выполнение

После этого:

письма отправляются
импорт работает
отложенные записи публикуются
задачи выполняются стабильно

И главное — поведение становится предсказуемым.

В продакшене псевдо-cron не место.

Read more on viku-lov.ru

Apache httpd и PHP-FPM: модули и расширения для продакшена (с учётом Bitrix)

Андрей Викулов (VProger) — Thu, 12 Feb 2026 05:29:51 +0000

Apache httpd и PHP-FPM: модули и расширения для продакшена (с учётом Bitrix)

Если вы работаете с Bitrix CMS, Laravel или чистым PHP — рано или поздно придётся разбираться, какие модули Apache и расширения PHP действительно нужны, а какие лишь мусор «на всякий случай».

Разберём:

полезные модули Apache httpd;
критичные расширения PHP для PHP-FPM;
что обязательно для Bitrix;
что даёт прирост производительности;
что лучше отключить.

Без теории ради теории. Только то, что реально влияет на прод.

Часть 1. Apache httpd — что реально нужно

Логотип Apache HTTP Server (Wikipedia)
Архитектура Apache worker MPM (ResearchGate)
mod_rewrite: обратные ссылки (документация Apache)
Синтаксис RewriteRule (документация Apache)

MPM: prefork vs event

❌ Prefork (устаревший подход)

каждый запрос = отдельный процесс
много памяти
актуален только при использовании mod_php

Если вы используете PHP-FPM (а так и стоит делать), prefork не нужен.

✅ MPM event (рекомендуется)

потоковая модель
меньше памяти
лучше под нагрузкой

Включение:


a2dismod mpm\_prefork

a2enmod mpm\_event

systemctl restart apache2

Для Bitrix:

На нагруженных проектах event + PHP-FPM даёт ощутимо лучшую стабильность.

mod_rewrite — без него никуда

Bitrix, Laravel, WordPress — все используют rewrite для ЧПУ и маршрутизации. Модуль использует PCRE-совместимые правила; описание директив — в официальной документации Apache mod_rewrite.

Базовый пример (запросы к несуществующим файлам и каталогам уходят в index.php):


<IfModule mod\_rewrite.c>

RewriteEngine On

RewriteCond %{REQUEST\_FILENAME} !-f

RewriteCond %{REQUEST\_FILENAME} !-d

RewriteRule ^(.\*)$ /index.php [L]

</IfModule>

!-f и !-d — условие: «если нет такого файла и нет такой директории» (см. RewriteCond).
Флаг L — остановить обработку правил после срабатывания.

Если приложение в подкаталоге (например, /bitrix-site/), нужен RewriteBase, иначе подстановка может дать неверный путь:


RewriteEngine On

RewriteBase /bitrix-site/

RewriteCond %{REQUEST\_FILENAME} !-f

RewriteCond %{REQUEST\_FILENAME} !-d

RewriteRule ^(.\*)$ index.php [L]

Без mod_rewrite ЧПУ и «красивые» URL в Bitrix и других CMS не работают.

mod_ssl — HTTPS обязателен

Шифрование по TLS обеспечивает mod_ssl (опирается на OpenSSL). SSLv2 не поддерживается; для продакшена оставляют только современные протоколы.

Проверка, что модуль загружен:


apachectl -M | grep ssl

Минимальный фрагмент виртуального хоста с Let's Encrypt (директивы SSLCertificateFile, SSLCertificateKeyFile):


<VirtualHost \*:443>

ServerName example.com

DocumentRoot /var/www/example.com

SSLEngine on

SSLCertificateFile /etc/letsencrypt/live/example.com/fullchain.pem

SSLCertificateKeyFile /etc/letsencrypt/live/example.com/privkey.pem

Только TLS 1.2 и 1.3 (SSLv3 отключён в современных сборках)

SSLProtocol all -SSLv3 -TLSv1 -TLSv1.1

</VirtualHost>

Рекомендуется также настроить SSLCipherSuite под актуальные рекомендации по безопасности. Bitrix без HTTPS — минус для SEO и безопасности; поисковики и браузеры помечают такие сайты как небезопасные.

mod_headers — контроль кэша и безопасности

mod_headers позволяет задавать и изменять HTTP-заголовки ответа. Для продакшена обычно выставляют заголовки безопасности и при необходимости — кэширование статики.

Безопасность (рекомендуемый минимум):


Header always set X-Content-Type-Options "nosniff"

Header always set X-Frame-Options "SAMEORIGIN"

Header always set X-XSS-Protection "1; mode=block"

Кэширование статики Bitrix (картинки, CSS/JS в /upload/, /local/): можно ограничить время кэша в браузере, чтобы не перегружать сервер повторными запросами к тем же файлам:


<IfModule mod\_headers.c>

<FilesMatch "\.(ico|webp|jpe?g|png|gif|css|js|woff2?)$">

Header set Cache-Control "public, max-age=2592000"

</FilesMatch>

</IfModule>

max-age=2592000 — 30 дней; для часто меняющихся ресурсов значение уменьшают.

mod_deflate / mod_brotli — сжатие

mod_deflate сжимает ответы по алгоритму DEFLATE (gzip). Поддерживается только gzip-кодирование для совместимости со старыми клиентами. Рекомендуемая конфигурация из документации Apache — сжимать только указанные MIME-типы:


<IfModule mod\_deflate.c>

AddOutputFilterByType DEFLATE text/html text/plain text/xml text/css text/javascript application/javascript application/json

</IfModule>

Не сжимайте уже сжатое (например, изображения в форматах с сжатием). На TLS-соединениях учитывайте риски класса атак BREACH при сжатии конфиденциального контента — для статики и типовых HTML/CSS/JS такая настройка безопасна.

Brotli (лучшая степень сжатия при сопоставимой скорости) — если в системе есть mod_brotli:


a2enmod brotli

Сжатие даёт заметное уменьшение трафика и ускорение загрузки страниц без изменения кода приложения.

mod_expires — кэширование статики

mod_expires выставляет заголовки Expires и Cache-Control: max-age по типу контента. Базовое время можно задать через access (от момента запроса) или modification (от даты изменения файла). Подробнее — в документации ExpiresByType.

Пример для типичной статики Bitrix (картинки, стили, скрипты):


<IfModule mod\_expires.c>

ExpiresActive On

ExpiresDefault "access plus 1 month"

ExpiresByType image/webp "access plus 1 year"

ExpiresByType image/jpeg "access plus 1 year"

ExpiresByType image/png "access plus 1 year"

ExpiresByType image/gif "access plus 1 year"

ExpiresByType text/css "access plus 1 month"

ExpiresByType application/javascript "access plus 1 month"

ExpiresByType font/woff2 "access plus 1 year"

</IfModule>

access plus 1 month означает: браузер может хранить копию 1 месяц с момента последнего запроса. Bitrix отдаёт много статики из /upload/ и шаблонов — корректные Expires снижают число запросов к серверу.

Часть 2. PHP-FPM — расширения, которые реально нужны

Логотип PHP (Wikipedia)
Схема работы PHP с веб-сервером (Storyblok)
Важность кэширования opcode (Accesto)
Производительность и кэширование (LinkedIn)

Переходим к PHP.

OPcache — обязательно

OPcache кэширует скомпилированный PHP-код (opcode) в памяти и значительно снижает нагрузку на CPU. Без него продакшен запускать не рекомендуется; настройка описана в официальной документации PHP и в Runtime Configuration.

Минимальная конфигурация для продакшена (в php.ini или в пуле PHP-FPM):


opcache.enable=1

opcache.memory\_consumption=256

opcache.max\_accelerated\_files=20000

opcache.validate\_timestamps=0

validate_timestamps=0 — не проверять изменение файлов на диске (максимальная производительность). После выката кода перезапускайте PHP-FPM или используйте скрипт сброса кэша.
Если оставляете validate_timestamps=1, задайте opcache.revalidate_freq=2 (проверка не чаще чем раз в 2 секунды), чтобы не дергать диск на каждый запрос.

Для Bitrix: OPcache ускоряет и публичную часть, и админку, снижает CPU; на проде он обязателен.

intl — обязательно для Bitrix

Расширение intl (Internationalization) нужно для работы с локалью, форматированием дат, чисел и строк в Unicode. Bitrix активно использует его в ядре и при работе с мультиязычностью и датами.

Проверка:


php -m | grep intl

Установка (Debian/Ubuntu):


apt install php8.2-intl

Без intl возможны ошибки при выводе дат, сортировке строк с кириллицей и в модулях, зависящих от ICU.

mbstring — обязательно

Многобайтовые строки, русский язык — без mbstring никуда.

mysqli / pdo_mysql

Bitrix работает с MySQL/MariaDB через mysqli или PDO. Обычно одно из расширений уже включено в сборке PHP.

Проверка:


php -m | grep -E 'mysqli|pdo\_mysql'

Если оба отключены — установите пакет, например: apt install php8.2-mysql.

redis — ускорение кэша Bitrix

Bitrix поддерживает Redis в качестве managed cache (вместо файлового или memcached). Настройка описана в документации Bitrix (подключения к Redis, Memcache).

Установка сервера и PHP-расширения:


apt install redis-server

apt install php8.2-redis

systemctl enable redis-server

В .settings.php (или в старом варианте в dbconn.php) задаётся тип кэша и параметры подключения:


'cache' => [

'value' => [

'type' => 'redis',

'redis' => [

'host' => '127.0.0.1',

'port' => '6379',

],

],

],

После смены кэша в настройках ядра Bitrix нужно сбросить кэш (Настройки → Производительность → Очистить кэш). На нагруженных проектах Redis даёт заметное ускорение по сравнению с файловым кэшем.

memcached — альтернатива Redis

Работает, но Redis сейчас предпочтительнее.

curl — обязателен

API, CRM, 1С, внешние сервисы.

Без curl Bitrix-интеграции страдают.

Bitrix обновления, архивы, маркетплейс.

gd / imagick

Обработка изображений.

Если проект с каталогом — imagick лучше.

Что лучше отключить

На продакшене отключают отладочные и избыточные опции.

В php.ini (или в конфиге пула FPM):


; Отладка — только в dev, на проде никогда

xdebug.mode = off

; Не выводить ошибки в ответ клиенту

display\_errors = Off

display\_startup\_errors = Off

; Логировать ошибки в файл

log\_errors = On

error\_log = /var/log/php-fpm/error.log

Xdebug на проде отключают: он сильно замедляет выполнение и может раскрывать внутреннюю информацию.
display_errors = On на проде недопустим: пользователь не должен видеть стек вызовов и пути к файлам.
allow_url_fopen — включать только если приложению нужен доступ к внешним URL через fopen; при использовании curl часто оставляют Off и ограничивают поверхность атак.

Проверка отключённых функций (часто хостеры режут shell_exec, exec и т.п.):


php -r "var\_dump(ini\_get('disable\_functions'));"

Продакшен — это минимум включённого и максимум контроля над тем, что реально используется.

Связка Apache и PHP-FPM

Чтобы Apache отдавал PHP-запросы в PHP-FPM, нужны модуль proxy_fcgi (и обычно proxy) и настройка проксирования. Пример для виртуального хоста (Unix-сокет):


<FilesMatch \.php$>

SetHandler "proxy:unix:/run/php/php8.2-fpm.sock|fcgi://localhost"

</FilesMatch>

Или через TCP (если FPM слушает порт):


<FilesMatch \.php$>

SetHandler "proxy:fcgi://127.0.0.1:9000"

</FilesMatch>

Путь к сокету смотрите в конфиге пула FPM (например, в /etc/php/8.2/fpm/pool.d/www.conf: listen = /run/php/php8.2-fpm.sock). Подробнее — в документации Apache (PHP-FPM) и в описании mod_proxy_fcgi.

Оптимальные настройки PHP-FPM для Bitrix

Параметры пула задаются в /etc/php/8.2/fpm/pool.d/www.conf (или отдельном файле пула). Рекомендуемый режим — dynamic: число воркеров меняется в заданных пределах. Документация: php.net FPM configuration.

Пример:


pm = dynamic

pm.max\_children = 30

pm.start\_servers = 5

pm.min\_spare\_servers = 5

pm.max\_spare\_servers = 10

pm.max\_requests = 500

Ориентир по памяти: если один PHP-процесс (Bitrix под нагрузкой) съедает около 100 МБ, то max_children = 30 — это до ~3 ГБ только на FPM. Учитывайте также Apache, MySQL, Redis и запас под пики — считайте под доступную RAM.

Типовая схема продакшена

Apache (mpm_event)
mod_rewrite
mod_ssl
PHP-FPM
OPcache
Redis
Правильные лимиты FPM

И вот это уже прод, а не «работает на локалке».

Частые проблемы

502 Bad Gateway

Apache не получает ответ от PHP-FPM. Возможные причины: FPM не запущен, закончились воркеры (max_children), таймаут при тяжёлом скрипте, неверный путь к сокету.

Проверка статуса и сокета:


systemctl status php8.2-fpm

ls -la /run/php/php8.2-fpm.sock

Проверка логов:


tail -f /var/log/apache2/error.log

tail -f /var/log/php8.2-fpm.log

Если 502 появляется под нагрузкой — увеличьте pm.max_children и убедитесь, что памяти хватает. При долгих запросах проверьте request_terminate_timeout в пуле FPM и таймауты в Apache (например, ProxyTimeout).

Медленная админка Bitrix

Типичные причины:

Нет OPcache — включите и перезапустите FPM.
Нет Redis — переведите managed cache на Redis в настройках ядра.
prefork вместо event — переключитесь на MPM event.
Маленький memory_limit — для тяжёлых страниц админки часто ставят 256M–512M.
Файловый кэш на медленном диске — замените на Redis.

Проверка OPcache в работе:


php -r "print\_r(opcache\_get\_status(false));"

Обновления Bitrix падают

При обновлении ядра или модулей проверьте:

Расширение zip — php -m | grep zip.
Расширение intl — обязательно для Bitrix.
Права на файлы — владелец и группа должны совпадать с пользователем веб-сервера; каталоги с записью для обновления.
disable_functions — в списке не должно быть exec, shell_exec, proc_open и т.п., если обновление их использует (официальная документация Bitrix уточняет требования к окружению).

Сниппеты по теме

Apache mod_rewrite: front controller для Bitrix и Laravel
Apache: привязка PHP к PHP-FPM через SetHandler
OPcache: настройка для продакшена (php.ini)
Bitrix: настройка Redis для managed cache (.settings.php)

Полезные ссылки по документации

Связанные статьи

Backend-автоматизация:

https://viku-lov.ru/blog/backend-cron-bitrix-agents-automation

CI/CD для PHP и Bitrix:

https://viku-lov.ru/blog/cicd-php-bitrix-laravel-github-actions

WordPress и OPcache (актуально и для Bitrix):

https://viku-lov.ru/blog/wordpress-performance-2026-core-web-vitals-lcp-inp-cls-nginx-phpfpm-opcache-caching

Итог

Если коротко:

Apache:

mpm_event
mod_rewrite
mod_ssl
mod_headers
mod_expires
mod_deflate / brotli

PHP:

opcache
intl
mbstring
mysqli
curl
redis
zip
gd / imagick

Остальное — по ситуации.

Если сервер нагружен — сначала проверьте:

OPcache
FPM max_children
Redis
MPM event

И только потом имеет смысл браться за «оптимизацию кода».

Read more on viku-lov.ru

Forem: Андрей Викулов (VProger)

Как создать блог на Astro: установка, MDX, Content Collections

Как конвертировать CHM в один PDF на Linux: без мусора и битых ссылок

Миграция с WordPress на Bitrix без потери SEO

Почему миграции с WordPress на Bitrix рушат SEO

WordPress: JSON-LD для CPT — дубли и ошибки

WordPress: JSON-LD для CPT — дубли и ошибки

В чём проблема

Реальный симптом

Почему это происходит

Рабочее решение

Шаг 1: Класс генерации JSON-LD для CPT

Шаг 2: Подключение в functions.php

Шаг 3: Альтернатива без класса (быстро и грубо, но работает)

Проверка результата

1) Проверка в исходнике

2) Быстрая проверка через curl

3) Проверка на дубли

4) Google Rich Results Test

Типичные ошибки

❌ Ошибка 1: JSON ломается из-за кавычек в заголовке

❌ Ошибка 2: Разметка дублируется

❌ Ошибка 3: Missing required field "author"

❌ Ошибка 4: JSON-LD не появляется на CPT

Если не работает: чеклист

Где применять

Связанные материалы

Итоги

Как включить GeoIP в Nginx: переменные для логов и заголовков

Как включить CPT в REST API WordPress: /wp/v2 отдаёт 404

Bitrix — проблема или просто инструмент?

WordPress: ACF поле не сохраняется — чиним запись meta

WordPress: ускоряем Nginx + PHP-FPM до TTFB меньше 300 мс

WordPress: как настроить системный cron вместо WP-Cron

Apache httpd и PHP-FPM: модули и расширения для продакшена (с учётом Bitrix)

Шаг 2: Подключение в `functions.php`

2) Быстрая проверка через `curl`

❌ Ошибка 3: `Missing required field "author"`