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

MySQL не запускается в BitrixVM: ошибка Unix socket lock file is empty

Андрей Викулов (VProger) — Fri, 26 Jun 2026 09:09:34 +0000

Недавно столкнулся с интересной проблемой на сервере с BitrixVM и Percona Server 5.7. На первый взгляд MySQL отказывался запускаться без каких-либо очевидных причин, а systemd выводил довольно бесполезное сообщение:

Initialization of mysqld failed: 0

Разберёмся, как диагностировать подобную проблему и почему в итоге помогло удаление файлов mysqld.sock и mysqld.sock.lock.

Симптомы

При попытке запуска MySQL сервис постоянно падал:

systemctl restart mysqld

Проверка статуса показывала:

systemctl status mysqld

Результат:

Initialization of mysqld failed: 0

При этом в системном журнале не было подробностей, поэтому пришлось смотреть лог MySQL.

Анализ логов

Открываем журнал ошибок:

tail -200 /var/log/mysql/error.log

В логе обнаружилась настоящая причина:

[ERROR] Unix socket lock file is empty /var/lib/mysqld/mysqld.sock.lock.
[ERROR] Unable to setup unix socket lock file.
[ERROR] Aborting

Самое интересное — InnoDB успешно проходил инициализацию:

InnoDB: Percona XtraDB started

То есть проблема была не в таблицах, не в повреждении базы данных и не в InnoDB.

Что такое mysqld.sock и mysqld.sock.lock

MySQL использует Unix Socket для локальных подключений.

На сервере обычно присутствуют файлы:

/var/lib/mysqld/mysqld.sock
/var/lib/mysqld/mysqld.sock.lock

Это служебные файлы.

Они не содержат данные базы и создаются автоматически при запуске сервера MySQL.

Если сервис завершился аварийно или файловая система была переполнена, эти файлы могут остаться в некорректном состоянии.

Дополнительная проблема

Параллельно обнаружилось, что корневой раздел практически полностью заполнен:

df -h

Результат:

/dev/vda1 158G 156G 2.3G 99%

Недостаток свободного места часто становится причиной подобных ошибок.

Решение

Сначала убедился, что процесс MySQL полностью остановлен:

pkill mysqld

После этого удалил служебные файлы:

rm -f /var/lib/mysqld/mysqld.sock
rm -f /var/lib/mysqld/mysqld.sock.lock

Запустил сервис заново:

systemctl start mysqld

После очистки повреждённого lock-файла сервер успешно стартовал.

Важно

Удаление файлов:

mysqld.sock
mysqld.sock.lock

не приводит к потере данных.

Это временные служебные файлы, которые MySQL создаёт автоматически при запуске.

Однако выполнять удаление следует только после полной остановки сервиса.

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

Если проблема повторяется:

Свободное место

df -h

Размер каталогов

du -xh / --max-depth=1 | sort -hr

Логи MySQL

tail -200 /var/log/mysql/error.log

Активные процессы

pgrep -a mysqld

Вывод

Если MySQL в BitrixVM или CentOS неожиданно перестал запускаться, а в логах присутствует ошибка:

Unix socket lock file is empty

не спешите восстанавливать базы или искать повреждение InnoDB.

В большинстве случаев проблема связана с повреждённым socket lock-файлом или нехваткой места на диске. Проверка логов и очистка служебных файлов позволяют восстановить работу сервиса за несколько минут.

Read more on Viku-Lov Studio

Личный диск Bitrix24 не открывается и не загружаются файлы: восстановление Storage пользователя

Андрей Викулов (VProger) — Fri, 26 Jun 2026 09:09:08 +0000

Симптомы

На одном из порталов Bitrix24 возникла странная ситуация.

У администратора перестал открываться личный диск:

/company/personal/user/14254/disk/path/

Вместо интерфейса диска отображалась обычная лента активности.

Дополнительно появилась ошибка при загрузке файлов через модуль Почта:

Недостаточно прав доступа для загрузки файла на сервер

При этом:

пользователь являлся администратором;
права доступа были корректны;
свободное место на сервере присутствовало;
другие сотрудники работали без проблем.

Первичная диагностика

Первое подозрение падает на модуль Disk.

Проверяем наличие пользовательского Storage:

$userId = 14254;
$storage = \Bitrix\Disk\Driver::getInstance()
->getStorageByUserId($userId);
var_dump($storage);

Результат:

NULL

Для сравнения проверяем рабочего пользователя:

$userId = 5;
$storage = \Bitrix\Disk\Driver::getInstance()
->getStorageByUserId($userId);
var_dump($storage);

Результат:

object(Bitrix\Disk\Storage)

Что означает NULL

Каждый пользователь Bitrix24 имеет собственное хранилище файлов.

Оно хранится в таблице:

b_disk_storage

Через него работают:

Личный диск;
Почта;
Чат;
Комментарии;
Задачи;
Прикрепление файлов.

Если Storage отсутствует, пользователь теряет возможность работать с файлами.

Проверка базы данных

Проверяем наличие записи:

SELECT *
FROM b_disk_storage
WHERE ENTITY_ID = 14254;

Результат:

0 rows

Запись отсутствовала.

Решение

Для восстановления хранилища используем штатный API Bitrix.

$userId = 14254;
$user = \Bitrix\Main\UserTable::getById($userId)->fetch();
$storage = \Bitrix\Disk\Driver::getInstance()
->addUserStorage($userId);
var_dump($storage);

После выполнения метода Bitrix автоматически:

создал Storage;
создал корневую папку;
зарегистрировал права доступа;
восстановил структуру пользовательского диска.

Результат

После создания Storage:

✅ открылся личный диск

✅ заработала загрузка файлов

✅ исчезла ошибка доступа

✅ восстановилась работа почтовых вложений

Как найти других пользователей без Storage

Полезный скрипт для аудита портала:

$rsUsers = \Bitrix\Main\UserTable::getList([
'select' => ['ID', 'LOGIN']
]);
while ($user = $rsUsers->fetch())
{
$storage = \Bitrix\Disk\Driver::getInstance()
->getStorageByUserId($user['ID']);
if (!$storage)
{
echo $user['ID'] . ' | ' . $user['LOGIN'] . PHP_EOL;
}
}

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

На практике такое встречается после:

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

Вывод

Если в Bitrix24 одновременно:

не открывается личный диск;
не прикрепляются файлы;
появляются ошибки доступа;

то первым делом проверьте наличие пользовательского Storage через:

\Bitrix\Disk\Driver::getInstance()
->getStorageByUserId($userId);

Возвращаемый NULL почти всегда указывает на отсутствие персонального хранилища пользователя.

В большинстве случаев проблема решается штатным методом:

\Bitrix\Disk\Driver::getInstance()
->addUserStorage($userId);

без вмешательства в базу данных и без переустановки модуля Disk.

Read more on Viku-Lov Studio

1С-Битрикс: кастомная страница настроек темы через Option API

Андрей Викулов (VProger) — Fri, 26 Jun 2026 07:01:26 +0000

1С-Битрикс: кастомная страница настроек темы через Option API

Задача: сделать свою страницу настроек темы и сохранить параметры так, чтобы они стабильно применялись в шаблоне сайта. В новой документации Битрикс для этой задачи есть все базовые элементы: работа с административной панелью, API опций модуля и стандартная защита формы от CSRF.

Официальные источники:

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

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

нет единой точки хранения;
настройки меняются небезопасно;
после обновлений или миграций часть параметров теряется;
сложно проверить, что именно применилось на фронте.

Для устойчивой схемы в Битрикс достаточно:

хранить настройки в Option;
отправлять форму только с CSRF-токеном;
читать настройки в шаблоне сайта в одном месте.

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

Ниже минимальный рабочий сценарий без недокументированных зависимостей.

Шаг 1. Добавляем кнопку открытия страницы настройки

Документация по панели администрирования показывает, что можно добавить свою кнопку через AddPanelButton.

<?php
// Например, в шаблоне после подключения пролога
$APPLICATION->AddPanelButton([
"ID" => "theme_settings",
"TEXT" => "Настройки темы",
"TYPE" => "BIG",
"SORT" => 100,
"HREF" => "/local/admin/theme_settings.php",
]);

API:

Если хотите открыть страницу в popup, используйте GetPopupLink:

https://docs.1c-bitrix.ru/api/classes/CAllMain.html#method\_GetPopupLink

Шаг 2. Делаем форму с CSRF-токеном

В новой документации по безопасности явно указаны bitrixsessidpost() и checkbitrixsessid().

<?php
require($_SERVER["DOCUMENT_ROOT"] . "/bitrix/modules/main/include/prolog_admin_before.php");
use Bitrix\Main\Config\Option;
$moduleId = "main";
if ($_SERVER["REQUEST_METHOD"] === "POST") {
if (!check_bitrix_sessid()) {
die("Invalid session");
}
$phone = trim((string)($_POST["theme_phone"] ?? ""));
$accent = trim((string)($_POST["theme_accent"] ?? ""));
Option::set($moduleId, "theme_phone", $phone);
Option::set($moduleId, "theme_accent", $accent);
}
$savedPhone = Option::get($moduleId, "theme_phone", "");
$savedAccent = Option::get($moduleId, "theme_accent", "#0a7c66");
?>
<form method="post">
<?= bitrix_sessid_post(); ?>
<label>Телефон в шапке</label><br>
<input type="text" name="theme_phone" value="<?= htmlspecialchars($savedPhone, ENT_QUOTES, "UTF-8"); ?>"><br><br>
<label>Акцентный цвет</label><br>
<input type="text" name="theme_accent" value="<?= htmlspecialchars($savedAccent, ENT_QUOTES, "UTF-8"); ?>"><br><br>
<button type="submit">Сохранить</button>
</form>

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

Шаг 3. Читаем настройки в шаблоне темы

Дальше используем те же ключи Option в шаблоне:

<?php
use Bitrix\Main\Config\Option;
$moduleId = "main";
$themePhone = Option::get($moduleId, "theme_phone", "+7 (000) 000-00-00");
$themeAccent = Option::get($moduleId, "theme_accent", "#0a7c66");
?>
<style>
:root { --theme-accent: <?= htmlspecialchars($themeAccent, ENT_QUOTES, "UTF-8"); ?>; }
</style>
<a href="tel:<?= htmlspecialchars($themePhone, ENT_QUOTES, "UTF-8"); ?>">
<?= htmlspecialchars($themePhone, ENT_QUOTES, "UTF-8"); ?>
</a>

Идея простая: одна точка сохранения и одна точка чтения. Это упрощает поддержку и перенос.

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

Проверяем по шагам:

Открыть страницу настроек через кнопку панели.
Сохранить значения.
Обновить публичную страницу и убедиться, что новые данные применились.

Быстрая проверка из HTML:

curl -s https://example.ru/ | grep -E "theme-accent|tel:"

Ожидаемый признак: в ответе видны обновленные значения цвета и телефона.

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

❌ Ошибка: сохраняют POST без проверки токена.

Причина: нет checkbitrixsessid().

Как исправить: добавить проверку и bitrixsessidpost() в форму.

❌ Ошибка: ключи в Option::set() и Option::get() не совпадают.

Причина: опечатки вроде themephone vs themetel.

Как исправить: вынести ключи в константы или использовать одинаковые литералы.

❌ Ошибка: выводят значение без экранирования.

Причина: прямой вывод пользовательского текста в HTML.

Как исправить: использовать htmlspecialchars(..., ENT_QUOTES, "UTF-8").

❌ Ошибка: ожидают, что кнопка панели появится для всех пользователей.

Причина: права и настройки панели зависят от пользователя/группы.

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

https://docs.1c-bitrix.ru/pages/cms-basics/admin-panel.html

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

В темах, где нужно управлять контактами, цветами и переключателями блоков.
В проектах с контент-редакторами, которым нужен простой интерфейс без правок кода.
В production, где важно централизованное хранение параметров.

Дополнительно по структуре проекта:

Read more on Viku-Lov Studio

1С-Битрикс: как настроить canonical через SetPageProperty и ShowMeta

Андрей Викулов (VProger) — Fri, 26 Jun 2026 07:00:35 +0000

1С-Битрикс: как настроить canonical через SetPageProperty и ShowMeta

Запрос, с которым обычно приходят: в индексе появляются дубли страниц, а canonical либо не выводится, либо выводится не там, где ожидается. В 1С-Битрикс это решается штатно через свойства страницы и раздела: SetPageProperty, SetDirProperty, ShowMeta. Ниже только рабочая схема по официальной документации, без кастомной магии.

Официальные источники:

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

Типовые симптомы:

canonical вообще отсутствует в <head>;
canonical задается, но не на всех страницах раздела;
в шаблоне есть вывод meta-тегов, но canonical не появляется;
на разных URL с одинаковым контентом нет единого канонического адреса.

Почему это происходит в Битрикс:

свойство canonical задано на странице, но в шаблоне не выведено через ShowMeta;
canonical ожидают из .section.php, но используют SetPageProperty вместо SetDirProperty;
свойство называется не так, как параметр в ShowMeta;
задают свойство поздно и не проверяют итоговый HTML.

Документация по шаблонам страниц прямо указывает, что поведение страницы определяется свойствами, которые можно задавать на уровне страницы и раздела: https://docs.1c-bitrix.ru/pages/cms-basics/page-templates.html#svojstva-stranic.

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

Ниже схема из трех шагов: вывод свойства в шаблоне, установка на странице, установка на раздел.

Шаг 1. Выводим canonical в `head` через `ShowMeta`

В шаблоне сайта (обычно в служебной части шапки) добавляем вывод свойства canonical:

<?php
// В head шаблона сайта
$APPLICATION->ShowMeta("canonical", "canonical");

Метод ShowMeta документирован в API CAllMain и выводит мета-тег для указанного свойства:

https://docs.1c-bitrix.ru/api/classes/CAllMain.html#method\_ShowMeta

Если canonical уже хранится в свойстве canonical, второй параметр можно не дублировать. Но в практической настройке удобнее явно фиксировать имя meta-поля.

Шаг 2. Задаем canonical для конкретной страницы

В нужной странице задаем свойство canonical:

<?php
require($_SERVER["DOCUMENT_ROOT"] . "/bitrix/header.php");
$APPLICATION->SetPageProperty("canonical", "https://example.ru/catalog/item-1/");
$APPLICATION->SetTitle("Карточка товара");
?>
<p>Контент страницы</p>
<?php require($_SERVER["DOCUMENT_ROOT"] . "/bitrix/footer.php"); ?>

Метод SetPageProperty:

https://docs.1c-bitrix.ru/api/classes/CAllMain.html#method\_SetPageProperty

Шаг 3. Задаем canonical на уровень раздела

Когда нужно единое поведение для раздела, используем SetDirProperty (обычно в .section.php):

<?php
// /catalog/.section.php
$sSectionName = "Каталог";
$arDirProperties = [];
$APPLICATION->SetDirProperty("canonical", "https://example.ru/catalog/");

Метод SetDirProperty:

https://docs.1c-bitrix.ru/api/classes/CAllMain.html#method\_SetDirProperty

Шаг 4. Проверяем текущее значение свойства в коде

Для диагностики можно проверить, какое значение реально видит страница:

<?php
$canonical = $APPLICATION->GetProperty("canonical");
if ($canonical !== "") {
echo "<pre>canonical: " . htmlspecialchars($canonical, ENT_QUOTES, "UTF-8") . "</pre>";
}

Метод GetProperty:

https://docs.1c-bitrix.ru/api/classes/CAllMain.html#method\_GetProperty

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

Проверяем, что canonical реально попал в итоговый HTML страницы.

curl -s https://example.ru/catalog/item-1/ | grep -i canonical

Ожидаемый результат:

<meta name="canonical" content="https://example.ru/catalog/item-1/">

Если у вас в проекте принято использовать <link rel="canonical">, это отдельная реализация в шаблоне. В этой статье рассматривается именно документированная схема через свойства и ShowMeta.

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

❌ Ошибка: свойство задают, но не выводят.

Причина: есть SetPageProperty, но нет ShowMeta в head.

Как исправить: добавить вызов ShowMeta("canonical", "canonical") в шаблон.

❌ Ошибка: ждут, что значение из раздела применится, но задают на странице.

Причина: путают SetPageProperty и SetDirProperty.

Как исправить: для раздела использовать SetDirProperty.

❌ Ошибка: canonical «пустой» в HTML.

Причина: разное имя свойства при установке и выводе (например, canon_url и canonical).

Как исправить: унифицировать идентификатор свойства во всех местах.

❌ Ошибка: проверяют только в браузере и не видят реальный HTML после правок.

Причина: не выполняют проверку через curl.

Как исправить: всегда проверять итоговую разметку командой из раздела выше.

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

SEO-настройка карточек и разделов каталога.
Проекты с дублирующими URL в публичной части.
Миграции и реструктуризация URL, где важно зафиксировать канонический адрес.
Поддержка больших разделов, где свойства удобнее задавать на уровне .section.php.

Полезно дополнительно:

Read more on Viku-Lov Studio

Как устранить ошибку Class not found в PHP: настройка автозагрузки PSR-4

Андрей Викулов (VProger) — Fri, 26 Jun 2026 07:00:11 +0000

Как устранить ошибку Class not found в PHP: настройка автозагрузки PSR-4

При переходе от процедурного кода к ООП часто возникает фатальная ошибка «класс не найден»: PHP не подключает файл с классом. В итоге проект обрастает десятками require, структура путается, поддержка усложняется. Ниже — пошаговое внедрение PSR-4 через Composer: классы начнут подгружаться автозагрузкой, структура проекта станет предсказуемой.

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

Классический симптом отсутствия стандартизированной структуры — постоянные падения скрипта при попытке создать объект нового класса или вызвать статический метод зависимого сервиса, который расположен в другом файле.

Пример реальной ошибки в логах веб-сервера (или прямо на экране, если включён вывод ошибок):


Fatal error: Uncaught Error: Class 'Database\Connection' not found in /var/www/html/index.php:5

Stack trace:

#0 {main}

thrown in /var/www/html/index.php on line 5

Эта ошибка возникает потому, что PHP-интерпретатор не знает, где физически лежит файл с описанием класса Connection из пространства имён Database. В старом, так называемом «legacy» коде это решалось исключительно ручным управлением зависимостями и путями:


<?php

// Антипаттерн: ручное подключение каждого файла при разрастании кодовой базы

require\_once \_\_DIR\_\_ . '/Database/Connection.php';

require\_once \_\_DIR\_\_ . '/Models/User.php';

require\_once \_\_DIR\_\_ . '/Services/EmailSender.php';

require\_once \_\_DIR\_\_ . '/Controllers/AuthController.php';

$db = new Database\Connection();

// Дальнейшая бизнес-логика...

Когда файлов становится больше сотни, управлять зависимостями вручную физически невозможно. Возникают циклические зависимости, дублирование путей и критические ошибки на production-сервере из-за банально забытого вызова require. Решение этой проблемы регламентировано стандартом PSR-4 от группы PHP-FIG, который диктует чёткое соответствие виртуального пространства имён (namespace) физической структуре директорий на диске. Это фундаментальное правило любого современного фреймворка или модульной системы.

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

Для автозагрузки отказываемся от ручных require и подключаем менеджер пакетов Composer. Он создаёт автозагрузчик по стандарту PSR-4 и сам подхватывает нужные файлы по имени класса и namespace.

Инициализация Composer и конфигурация файлов

Убедитесь, что вы находитесь в корне вашего проекта и у вас установлен консольный Composer. Создайте или обновите базовый конфигурационный файл composer.json для описания архитектуры вашего приложения:


{

"name": "vproger/php-oop-example",

"description": "Пример настройки PSR-4 автозагрузки в чистом PHP проекте",

"autoload": {

"psr-4": {

"App\\": "src/"

}

}

}

Здесь блок autoload с ключом psr-4 напрямую указывает менеджеру пакетов, что все PHP-классы, расположенные в корневом пространстве имён App, будут физически находиться внутри директории src/ относительно корня проекта. Обратите внимание на двойной слэш \ — он обязателен в формате JSON для экранирования разделителя пространства имён.

Создание физической структуры директорий

Создайте директорию src и воспроизведите в ней структуру, которая будет строго соответствовать вашим будущим пространствам имён. Написание директорий должно полностью совпадать с регистрами (Capitalized):


mkdir -p src/Database

mkdir -p src/Services

Теперь создадим класс для подключения к базе данных. Создайте файл по пути src/Database/Connection.php:


<?php

namespace App\Database;

use PDO;

class Connection

{

private PDO $pdo;

public function \_\_construct(string $dsn, string $user, string $password)

{

// Инициализация соединения с базой

$this->pdo = new PDO($dsn, $user, $password);

$this->pdo->setAttribute(PDO::ATTR\_ERRMODE, PDO::ERRMODE\_EXCEPTION);

}

public function getPdo(): PDO

{

return $this->pdo;

}

}

Критически важно: пространство имён App\Database строго соответствует физическому пути src/Database. Имя файла Connection.php в точности совпадает с названием класса Connection.

Создадим второй класс, который будет использовать наш коннект. Создадим сервис для работы с пользователями в файле src/Services/UserService.php:


<?php

namespace App\Services;

use App\Database\Connection;

class UserService

{

private Connection $db;

public function \_\_construct(Connection $db)

{

$this->db = $db;

}

public function getUser(int $id): array

{

// В реальном проекте здесь был бы SQL-запрос через $this->db->getPdo()

return [

'id' => $id,

'name' => 'Алексей',

'role' => 'admin'

];

}

}

Бинарная генерация автозагрузчика файлов и точка входа

Выполните команду для генерации файлов автозагрузки в терминале. Эту операцию нужно запускать каждый раз, когда вы меняете секцию autoload или базовые правила путей в файле composer.json:


composer dump-autoload -o

Обязательный флаг -o (--optimize) создаёт оптимизированную карту классов, сканируя все директории. Это необходимо для обеспечения максимальной производительности, чтобы автозагрузчику не приходилось каждый раз использовать дорогостоящие операции файловой системы file_exists().

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


<?php

// Единственный обязательный require во всём вашем проекте!

require \_\_DIR\_\_ . '/vendor/autoload.php';

// Импортируем классы для использования

use App\Database\Connection;

use App\Services\UserService;

try {

// Теперь PHP автоматически найдёт и подключит нужные файлы "на лету"

$connection = new Connection('mysql:host=localhost;dbname=test', 'root', 'secret');

$userService = new UserService($connection);

$user = $userService->getUser(1);

header('Content-Type: application/json; charset=utf-8');

echo json\_encode($user, JSON\_UNESCAPED\_UNICODE);

} catch (\Throwable $e) {

echo "Критическая ошибка: " . $e->getMessage();

}

Первый аргумент Connection — DSN (строка подключения к БД). Больше никаких ручных require_once. Код стал масштабируемым, полностью соответствует принципам ООП и готов к расширению. Добавление сотен новых сервисов, контроллеров или репозиториев не потребует никаких правок в логике подключения.

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

Чтобы убедиться, что автозагрузка работает правильно и нигде не сломана маршрутизация классов, запустите встроенный сервер PHP прямо в корне проекта:


php -S localhost:8080

Затем в другом окне системного терминала (или через клиент вроде Postman/Insomnia) выполните HTTP-запрос для проверки:


curl -i http://localhost:8080/index.php

Ожидаемый вывод, если всё сделано без ошибок:


HTTP/1.1 200 OK

Host: localhost:8080

Date: Sun, 01 Mar 2026 20:00:00 GMT

Connection: close

X-Powered-By: PHP/8.2.0

Content-Type: application/json; charset=utf-8

{"id":1,"name":"Алексей","role":"admin"}

Как понять, что всё прошло успешно:

Вывод точно соответствует ожидаемому JSON, скрипт полностью отрабатывает и не обрывается фатальной ошибкой Class not found.
В созданной директории vendor существует корневой файл autoload.php.
В файле vendor/composer/autoload_psr4.php (его создаёт Composer) есть запись вида array($baseDir . '/src'), связывающая префикс пространства имён с директорией.

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

Чаще всего PSR-4 автозагрузка перестаёт работать по таким причинам:

❌ Ошибка регистров в именах файлов или директорий (Самая частая проблема)
Причина: В операционной системе Windows (и при использовании локальных сред вроде XAMPP) файловые пути регистронезависимы, поэтому namespace App\database без проблем подключит папку src/Database. Но при деплое на Linux (например, Ubuntu/Debian на production-сервере) файловая система строго регистрозависима (case-sensitive). В результате рабочий локальный проект мгновенно падает в production с ошибкой загрузчика.
Как исправить: Строго следите за абсолютным совпадением регистра. Имена директорий и файлов должны в точности, до заглавной буквы, повторять ваши неймспейсы и имена реальных классов. Файл Connection.php лежит строго в папке Database, а класс назван Connection.
❌ Забыта команда перегенерации composer dump-autoload
Причина: Вы добавили новый префикс модуля или изменили базовую директорию в конфигурации composer.json, структура поменялась, но вы не перегенерировали кэш-файл автозагрузчика. Composer банально ещё не знает о ваших новых настройках.
Как исправить: После любых инфраструктурных изменений в секции autoload выполняйте директиву composer dump-autoload -o. В CI/CD пайплайне или в Docker-контейнере эту команду нужно обязательно добавлять в сборочный скрипт перед стартом веб-приложения.
❌ Несоответствие пространства имён физическому пути файла
Причина: Вы скопировали старый класс из другого проекта, где исторически был namespace OldProject\Models, положили его в новую папку src/Services, и автозагрузчик логично не может его найти, так как ожидает строгий namespace App\Services.
Как исправить: Откройте целевой файл скопированного класса и исправьте самую первую строку объявления namespace на корректную для текущего приложения. В современных средах разработки, таких как PhpStorm, следует всегда использовать функцию рефакторинга: выделите класс, затем отправьте команду Refactor -> Move Namespace, чтобы IDE сама поменяла все пути и импорты зависимостей.

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

PSR-4 через Composer — стандарт для современного PHP. Его стоит использовать везде:

Работающие production окружения (в классической связке веб-сервера Nginx/PHP-FPM).
Изолированные микросервисы в Docker-контейнерах в Kubernetes-кластерах.
CI/CD пайплайны развёртывания (команда composer install --no-dev --optimize-autoloader строго обязательна перед деплоем кода на сервер).
Разработка бизнес-модулей в системах, так как полезно применять правильную файловую структуру в 1С-Битрикс.
Модернизация старых систем и правильное использование новых возможностей и типизации в PHP 8.3/8.4, чтобы архитектура не отставала от языка.
Рефакторинг старых legacy-приложений перед обновлением на будущий PHP 8.5 и старше, где требования к чистоте кода возрастают экспоненциально.

Сниппеты по статье: Composer: composer.json PSR-4 · composer dump-autoload -o · Точка входа require vendor/autoload · Проверка php -S и curl

Термины словаря: Composer · PHP-FIG · Fatal error · require/include · Case-sensitive · DSN · Менеджер пакетов · Зависимость

Read more on viku-lov.ru

Закон об англицизмах 2026: что изменилось на самом деле

Андрей Викулов (VProger) — Fri, 26 Jun 2026 06:59:42 +0000

Что означает закон об англицизмах в России с 2026 года на самом деле

Коротко: запрета английских слов нет. Требование одно — информация для потребителя должна быть доступна на русском. Вывеска «Coffee» допустима, если рядом есть «Кофе» того же размера. Бренды, слова из словарей и техобозначения не трогают.

С марта 2026 года начали действовать обновлённые требования к использованию русского языка в публичной информации. В новостях это часто подают как «запрет английских слов», что звучит громко, но не совсем точно.

Разберём спокойно, без эмоций: что именно изменилось, кому это важно и где преувеличения.

В чём суть изменений

Главный принцип закона простой:

информация для потребителя должна быть доступна на русском языке.

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

Важно: закон не предписывает «убрать всё английское». Он требует, чтобы информация была доступна на русском. Как именно это оформить (две строки на вывеске, табличка рядом, дублирование в меню) — вопрос практики и дизайна, в рамках требований к заметности и читаемости русского текста.

Кого это касается

В первую очередь:

магазины
кафе и рестораны
сервисные компании
застройщики
реклама услуг
публичная навигация
точки общепита и розницы с вывесками на иностранном языке

Обычных людей закон не касается.

Разговорная речь, переписка, соцсети и личные блоги под регулирование не попадают. То есть писать посты или комментарии на любом языке по-прежнему можно; закон касается только той информации, которую бизнес адресует потребителю в момент оказания услуг или продажи товаров.

Что изменится на практике

Если используется иностранное слово в публичной информации, рядом должен быть русский вариант.

Например:

Coffee → Кофе
Sale → Распродажа
Beauty Studio → Студия красоты
Delivery → Доставка
Open 24/7 → Круглосуточно

При этом русский текст должен быть:

сопоставим по размеру
читаемым
понятным
не менее заметным

Фактически речь идёт не о запрете английского языка, а о дублировании информации. То есть вывеска «Coffee & Cake» допустима, если рядом или под ней тем же размером написано «Кофе и выпечка» (или аналогичный понятный вариант). Проверяющие смотрят не на наличие иностранных слов, а на то, может ли потребитель понять предложение без знания другого языка.

Можно ли использовать английский

Да.

Запрета иностранного языка нет.

Можно писать:

Кофейня — Coffee

Coffee — Кофейня

Оба варианта допустимы. Порядок («сначала русский» или «сначала английский») законом не задаётся — важно наличие обоих вариантов и соблюдение требований к размеру и заметности русского текста.

Когда ничего менять не нужно

Есть важные исключения.

Бренды и товарные знаки

Если название зарегистрировано как бренд:

Apple
Nike
Ozon
Wildberries

Перевод не требуется.

Это прямо предусмотрено законодательством. То есть сеть кофеен или магазин одежды с иностранным названием бренда в вывеске не обязан добавлять русский перевод названия самого бренда — достаточно, чтобы тип деятельности (например, «кофейня», «одежда») был понятен потребителю, если это требуется по смыслу нормы.

Слова, ставшие частью русского языка

Например:

интернет
маркетинг
менеджер
роутер
офис
сайт
онлайн
офлайн
дилер
дистрибьютор

Если слово зафиксировано в нормативных словарях русского языка, оно считается допустимым без обязательного дублирования.

Технические обозначения

Не требуют перевода общепринятые технические обозначения и аббревиатуры:

Wi-Fi
USB
QR
Bluetooth
HDMI
4G / 5G
LED

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

Можно ли сделать две вывески

Да. Это один из самых безопасных вариантов: например, «Coffee» и «Кофе» рядом, или две строки — «Beauty Studio» и «Студия красоты». Главное условие — русский текст должен присутствовать и быть не менее заметным, чем иностранный (размер, контраст, читаемость). Убирать английский не обязательно.

Штрафы

Отдельного штрафа «за английские слова» не существует.

Нарушение может квалифицироваться как предоставление неполной информации потребителю. Размеры штрафов сопоставимы с обычными административными нарушениями в торговле и не выглядят экстремальными. Конкретные суммы и формулировки лучше уточнять в актуальных редакциях КоАП и разъяснениях Роспотребнадзора по вашему региону. Отдельных «мегаштрафов» за одно иностранное слово на вывеске закон не вводит.

Почему возникло ощущение запрета

Причина — формулировки в новостях. Когда говорят «запрет англицизмов», создаётся впечатление масштабных ограничений.

Фактически речь идёт о более узкой норме: обеспечить информацию на государственном языке там, где бизнес обращается к потребителю. Подобные требования (обязательное дублирование или приоритет государственного языка в вывесках и рекламе) существуют во многих странах — от Франции до Казахстана. Цель не в том, чтобы запретить иностранные слова, а в том, чтобы человек мог понять предложение без знания другого языка. Поэтому в новостях и стоит различать: «запрет англицизмов» — это упрощение; по факту речь о норме доступности информации на государственном языке в сфере потребления.

Что важно понимать

Закон:

не регулирует речь людей
не запрещает иностранные слова
не заставляет менять бренды
не влияет на IT-термины
касается только публичной информации для потребителей

Иными словами: личные соцсети, переписка в мессенджерах, внутренние документы компании и разговорная речь остаются без изменений. Регулируется только то, что видит или слышит потребитель в момент выбора товара или услуги — вывески, реклама, меню, объявления в местах продаж.

Что сделать предпринимателю

Если у вас офлайн-точка, вывеска или реклама с иностранными словами:

Проверить вывеску и витрину — есть ли рядом с иностранным текстом русский вариант. Если нет, добавить: тот же размер, читаемость, заметность.
Бренды не трогать — зарегистрированные товарные знаки (названия компаний, продуктов) переводить не нужно.
Меню и прайсы — дублировать на русском ключевые пункты (названия блюд, услуг, акции). Не обязательно переводить каждое слово, если контекст понятен.
При сомнениях — уточнить в юридической консультации или в территориальном управлении Роспотребнадзора, как норму применяют в вашей сфере.

Для интернет-магазинов и соцсетей требования те же: информация для потребителя должна быть доступна на русском. Обычно достаточно описаний товаров и условий на сайте на русском языке.

Где смотреть точные требования

Официальные разъяснения даёт Роспотребнадзор; нормы опираются на закон о государственном языке РФ и подзаконные акты. Точные формулировки и практику применения по регионам лучше уточнять на сайте управления Роспотребнадзора по вашему субъекту или у юриста, который специализируется на защите прав потребителей и рекламе. Это поможет понять, как трактуют «сопоставимость» размера шрифта и «доступность» информации в вашем конкретном случае.

Итог

Самое точное описание изменений звучит так: если написано SALE, должно быть написано РАСПРОДАЖА. Без драматизации. Английский можно оставлять, бренды не переименовывать, техобозначения и слова из словарей не трогать. Меняются только правила оформления публичной информации для потребителя: русский вариант должен быть доступен и заметен. Для большинства предпринимателей это сводится к проверке вывесок и рекламы и при необходимости добавлению дублирования.

Вывод

Пока рано говорить о серьёзных последствиях. Скорее всего изменения будут точечными и затронут в первую очередь офлайн-вывески и рекламу. Для повседневной жизни большинства людей ничего не меняется; основные изменения касаются оформления офлайн-точек и рекламы.

Главное: закон не запрещает английский, а требует, чтобы информация для потребителя была доступна на русском. Соблюдение сводится к дублированию — например, «SALE» и «Распродажа» рядом, без драмы и без переписывания брендов.

Полный текст статьи на сайте; в Дзене — анонс и ссылка.

Read more on viku-lov.ru

Как настроить canonical, sitemap и RSS в Astro для индексации

Андрей Викулов (VProger) — Fri, 26 Jun 2026 06:58:22 +0000

Как настроить canonical, sitemap и RSS в Astro для индексации

Проблема: страницы блога на Astro не индексируются в Яндексе, попадают в LOW_DEMAND или дублируются в выдаче.

Решение: canonical из origin (не из Astro.url.href), sitemap.xml с фильтрацией черновиков, robots.txt с Sitemap, RSS с автообнаружением, meta description до 155 символов, Open Graph с абсолютными URL.

В чём проблема: почему страницы не индексируются

Типичные ошибки в Astro-проектах:

Canonical из Astro.url.href — на localhost и production получаются разные URL
Нет site в конфиге — sitemap и RSS не знают домен
Домен в — занимает место в выдаче</li> <li>Одинаковый description на всех страницах — слабый сигнал для поисковиков</li> <li>Относительный og:image — соцсети не подхватывают превью</li> <li>В sitemap попадают черновики — индексируются незавершённые страницы</li> </ol> Результат: LOW_DEMAND в Яндекс Вебмастере, дубли страниц, плохие сниппеты в выдаче. <hr> Рабочее решение: пошаговая настройка Шаг 1: Задаём site в astro.config.mjs <div class="highlight"><pre class="highlight javascript"><code> // astro.config.mjs import { defineConfig } from "astro/config"; export default defineConfig({ site: "https://example.com", // Полный URL с протоколом // ... }); </code></pre></div> Важно: указывай полный URL с протоколом (https://). Без site интеграция @astrojs/sitemap не заработает. Шаг 2: Canonical только из origin + pathname <div class="highlight"><pre class="highlight typescript"><code> // В компоненте SeoHead.astro const origin = "https://example.com"; // Из astro.config.mjs site const pathname = Astro.url.pathname; const search = Astro.url.search; const canonical = ${origin}${pathname}${search || ""}; </code></pre></div> Почему не Astro.url.href: в dev-режиме Astro.url может быть <a href="http://localhost:4321">http://localhost:4321</a>, а в проде — твой домен. Поисковики хотят видеть один стабильный каноничный адрес. Шаг 3: Создаём компонент SeoHead.astro Создай файл src/components/SeoHead.astro: <div class="highlight"><pre class="highlight plaintext"><code> --- const { title = "Сайт", description = "", canonicalUrl, ogImage = "/assets/og-default.png", noIndex = false, } = Astro.props; // Origin из конфига (один источник правды) const origin = "https://example.com"; const pathname = Astro.url.pathname; const search = Astro.url.search; const canonical = canonicalUrl ?? ${origin}${pathname}${search || ""}; // Убираем домен из title (если есть) const titleWithoutDomain = title.replace(/\s_[|\-—]\s_example\.com\s\*$/i, "").trim() || title; const safeDescription = description.slice(0, 155).trim(); --- <title>{titleWithoutDomain}</title> <meta name="description" content={safeDescription} /> <link rel="canonical" href={canonical} /> {noIndex ? ( <meta name="robots" content="noindex, nofollow" /> ) : ( <meta name="robots" content="index, follow" /> )}  <meta property="og:title" content={titleWithoutDomain} /> <meta property="og:description" content={safeDescription} /> <meta property="og:type" content="website" /> <meta property="og:url" content={canonical} /> <meta property="og:image" content={${origin}${ogImage}} /> <meta property="og:locale" content="ru\_RU" />  <meta name="twitter:card" content="summary\_large\_image" /> <meta name="twitter:title" content={titleWithoutDomain} /> <meta name="twitter:description" content={safeDescription} /> <meta name="twitter:image" content={${origin}${ogImage}} /> <slot /> </code></pre></div> Шаг 4: Используем SeoHead в layout <div class="highlight"><pre class="highlight plaintext"><code> --- import SeoHead from "../components/SeoHead.astro"; const { title = "Сайт", description = "", canonicalUrl, ogImage, noIndex } = Astro.props; --- <head> <meta charset="utf-8" /> <meta name="viewport" content="width=device-width, initial-scale=1" /> <SeoHead title={title} description={description} canonicalUrl={canonicalUrl} ogImage={ogImage} noIndex={noIndex} /> </head> <body> <slot /> </body> </code></pre></div> Шаг 5: Создаём robots.txt Положи файл в public/robots.txt: <div class="highlight"><pre class="highlight plaintext"><code> User-agent: \* Allow: / Disallow: /admin/ Disallow: /api/ User-agent: Yandex Allow: / Disallow: /admin/ Disallow: /api/ Sitemap: https://example.com/sitemap.xml </code></pre></div> Шаг 6: Генерация sitemap.xml Вариант A: интеграция @astrojs/sitemap (SSG) <div class="highlight"><pre class="highlight shell"><code> pnpm astro add sitemap </code></pre></div> В astro.config.mjs должен быть задан site. Интеграция сгенерирует sitemap.xml в dist. Ограничение: в sitemap попадут только статические страницы. Для блога на Content Collections этого обычно достаточно. Вариант B: кастомный endpoint (SSR или полный контроль) Создай файл src/pages/sitemap.xml.ts: <div class="highlight"><pre class="highlight typescript"><code> import type { APIRoute } from "astro"; import { getCollection } from "astro:content"; const SITE = "https://example.com"; function formatLastmod(d: Date | undefined): string | undefined { return d ? d.toISOString().split("T")[0] : undefined; } export const prerender = false; export const GET: APIRoute = async () => { const posts = await getCollection("blog", ({ data }) => !data.draft); const urls = [ { url: SITE, changefreq: "daily", priority: "1.0" }, { url: ${SITE}/blog, changefreq: "weekly", priority: "0.9" }, ...posts.map((p) => ({ url: ${SITE}/blog/${p.data.slug ?? p.slug}, lastmod: formatLastmod(p.data.updatedDate ?? p.data.pubDate), changefreq: "monthly" as const, priority: "0.8", })), ]; const xml = `<?xml version="1.0" encoding="UTF-8"?> <urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9"> ${urls .map( (u) => ` <url> <loc>${u.url}</loc> ${u.lastmod ? <lastmod>${u.lastmod}</lastmod> : ""} <changefreq>${u.changefreq}</changefreq> <priority>${u.priority}</priority> </url>` ) .join("\n")} </urlset>`; return new Response(xml, { headers: { "Content-Type": "application/xml; charset=utf-8" }, }); }; </code></pre></div> Шаг 7: Настраиваем RSS <div class="highlight"><pre class="highlight shell"><code> pnpm add @astrojs/rss </code></pre></div> Создай файл src/pages/rss.xml.ts: <div class="highlight"><pre class="highlight typescript"><code> import rss from "@astrojs/rss"; import { getCollection } from "astro:content"; export async function GET(context: any) { const posts = (await getCollection("blog")) .filter((p) => !p.data.draft) .sort((a, b) => b.data.pubDate.valueOf() - a.data.pubDate.valueOf()); return rss({ title: "Блог Example", description: "Заметки о разработке", site: context.site?.href ?? "https://example.com", items: posts.map((p) => ({ title: p.data.title, description: p.data.description ?? "", pubDate: p.data.pubDate, link: /blog/${p.data.slug ?? p.slug}/, })), }); } </code></pre></div> В <head> основного layout добавь: <div class="highlight"><pre class="highlight html"><code> <link rel="alternate" type="application/rss+xml" title="RSS" href="/rss.xml" /> </code></pre></div> <hr> Проверка результата <ol> <li>Проверка canonical </li> </ol> <div class="highlight"><pre class="highlight shell"><code> Проверить заголовок canonical curl -s https://example.com/blog/astro-part-1/ | grep canonical Должно быть: <link rel="canonical" href="https://example.com/blog/astro-part-1/"> </code></pre></div> <ol> <li>Проверка robots.txt </li> </ol> <div class="highlight"><pre class="highlight shell"><code> Проверить наличие Sitemap curl -s https://example.com/robots.txt | grep Sitemap </code></pre></div> <ol> <li>Проверка sitemap.xml </li> </ol> <div class="highlight"><pre class="highlight shell"><code> Проверить наличие URL постов curl -s https://example.com/sitemap.xml | grep "blog/" </code></pre></div> <ol> <li>Проверка в Яндекс Вебмастере</li> <li>Открыть <a href="https://webmaster.yandex.ru/">Яндекс Вебмастер</a></li> <li>Добавить сайт</li> <li>Проверить разделы:</li> </ol> <ul> <li>Индексирование → Sitemap — должна быть загружена</li> <li>Диагностика → Страницы в поиске — проверить наличие страниц</li> <li>Поведение в выдаче — посмотреть CTR и позиции</li> </ul> <hr> Типичные ошибки ❌ Нет site в конфиге Проблема: sitemap и RSS не знают домен, canonical собирается неправильно. Решение: задать site в astro.config.mjs. ❌ Canonical из Astro.url.href Проблема: на localhost и production получаются разные каноничные URL. Решение: использовать origin из конфига + pathname. ❌ Домен в <title> Проблема: занимает место в выдаче. Решение: убрать домен из title или использовать короткое имя сайта. ❌ Одинаковый description на всех страницах Проблема: слабый сигнал для поисковиков. Решение: делать уникальные описания до ~155 символов. ❌ Относительный og:image Проблема: соцсети не подхватывают превью. Решение: использовать абсолютный URL (origin + путь). ❌ В sitemap попадают черновики Проблема: индексируются незавершённые страницы. Решение: фильтровать по draft: false при генерации sitemap. <hr> Где применять <ul> <li>Блоги на Astro: индексация статей в Яндексе и Google</li> <li>Документация: правильное отображение в поиске</li> <li>Маркетинговые сайты: улучшенные сниппеты в выдаче</li> <li>Портфолио: индексация проектов</li> </ul> Связанные статьи: <ul> <li>Как создать блог на Astro</li> <li>Actions, API Routes, SSR и деплой</li> </ul> Документация: <ul> <li><a href="https://docs.astro.build/en/reference/configuration-reference/">Astro Configuration Reference</a></li> <li><a href="https://docs.astro.build/en/guides/integrations-guide/sitemap/">Sitemap Integration</a></li> <li><a href="https://docs.astro.build/en/guides/rss/">RSS Guide</a></li> </ul> <hr> Чек-лист для Яндекс Вебмастера <ul> <li>[] site в astro.config.mjs задан и совпадает с основным зеркалом</li> <li>[] На каждой странице есть один <link rel="canonical"> с абсолютным URL</li> <li>[] meta description уникален и длиной до ~155 символов</li> <li>[] <title> без домена, осмысленный для каждой страницы</li> <li>[] robots.txt доступен с Sitemap:</li> <li>[] sitemap.xml открывается по URL из robots.txt</li> <li>[] Open Graph : og:title, og:description, og:url, og:image (абсолютный URL)</li> <li>[] Служебные разделы (/admin/, /api/) закрыты в robots.txt</li> <li>[] RSS доступен и объявлен в <head></li> <li>[] Нет дублей страниц (одинаковый контент по разным URL без canonical)</li> </ul> <a href="https://viku-lov.ru/blog/astro-seo-sitemap-rss-setup">Read more on viku-lov.ru</a>

Как создать блог на 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

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

MySQL не запускается в BitrixVM: ошибка Unix socket lock file is empty

Симптомы

Анализ логов

Что такое mysqld.sock и mysqld.sock.lock

Дополнительная проблема

Решение

Важно

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

Свободное место

Размер каталогов

Логи MySQL

Активные процессы

Вывод

Личный диск Bitrix24 не открывается и не загружаются файлы: восстановление Storage пользователя

Симптомы

Первичная диагностика

Что означает NULL

Проверка базы данных

Решение

Результат

Как найти других пользователей без Storage

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

Вывод

1С-Битрикс: кастомная страница настроек темы через Option API

1С-Битрикс: кастомная страница настроек темы через Option API

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

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

Шаг 1. Добавляем кнопку открытия страницы настройки

Шаг 2. Делаем форму с CSRF-токеном

Шаг 3. Читаем настройки в шаблоне темы

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

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

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

1С-Битрикс: как настроить canonical через SetPageProperty и ShowMeta

1С-Битрикс: как настроить canonical через SetPageProperty и ShowMeta

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

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

Шаг 1. Выводим canonical в head через ShowMeta

Шаг 2. Задаем canonical для конкретной страницы

Шаг 3. Задаем canonical на уровень раздела

Шаг 4. Проверяем текущее значение свойства в коде

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

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

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

Как устранить ошибку Class not found в PHP: настройка автозагрузки PSR-4

Закон об англицизмах 2026: что изменилось на самом деле

Как настроить canonical, sitemap и RSS в Astro для индексации

Как создать блог на 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

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

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

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

Итоги

Шаг 1. Выводим canonical в `head` через `ShowMeta`

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

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

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