WordPress или Joomla: языки, права и поддержка

WordPress или Joomla: языки, права и поддержка решаются на конкретной реализации. Для учебного сайта кружка с четырьмя материалами — RU-новостью «Открыт набор», её EN-парой «Enrollment is open», расписанием «Среда 18:00» и его парой «Wednesday 18:00» — сравниваются две сборки: самостоятельно размещаемый WordPress.org и Joomla 6.x. Ниже — что именно настраивать, как проверять права и какой хостинг подходит.

Четыре материала, языковые пары и три учётные роли

Учебный сайт кружка держит четыре отдельных материала: N01 «Открыт набор», N01-EN «Enrollment is open», S01-RU «Среда 18:00» и S01-EN «Wednesday 18:00». Все четыре существуют как отдельные записи, и установка языкового пакета сама перевода не создаёт. Перевод делает человек, а CMS связывает пары.

Учётных роли три. Анна — администратор. Борис — редактор новостей: он публикует N01 и N01-EN. Вера — редактор расписания: она ведёт S01-RU и S01-EN. Разделение обязанностей между Борисом и Верой — главное требование к правам.

Реализаций две, и они альтернативные, на отдельных тестовых установках. В WordPress выбранный рецепт: Multisite с двумя языковыми сайтами, новости как post, расписание как custom post type schedule_item. В Joomla: языковые категории и меню, группы NewsEditors и ScheduleEditors, действия по категориям.

Карта языковых URL задаётся договором: /ru/news/open ↔ /en/news/open, /ru/schedule/wed ↔ /en/schedule/wed. Это требуемые адреса учебного сайта. Материалы и меню связываются с этими адресами вручную, чтобы переключатель не отправлял с новости на главную.

Условный хост для обеих сборок: PHP 8.4, MariaDB 12.0, Apache 2.4, HTTPS. Нужные модули PHP проверяются по выбранной CMS. Этого достаточно для приведённых таблиц требований, но наличие подходящего шаблона или расширения это не доказывает.

Языковые пары: как связать переводы

В WordPress ядро не делает сайт двуязычным из коробки. В официальном руководстве по multilingual WordPress прямо сказано, что поддержки двуязычного блога «out-of-the-box» нет, а сообщество предлагает плагины. Один из описанных там подходов — отдельная установка на каждый язык, в том числе сеть Multisite: сайты используют общее ядро, но имеют отдельные таблицы в базе. Именно этот вариант выбран для учебного сайта.

Практический порядок для WordPress-рецепта:

1. Включить Multisite, добавив в wp-config.php строку define( 'WP_ALLOW_MULTISITE', true ); выше комментария о завершении редактирования.
2. Создать сеть и выбрать схему адресов — поддомены или подкаталоги.
3. Завести два языковых сайта и связать пары N01↔N01-EN, S01-RU↔S01-EN в меню и шаблоне.
4. Проверить переключатель: с N01 он должен вести к «Enrollment is open», с расписания — к «Wednesday 18:00».

В Joomla ядро предоставляет multilingual framework. По руководству Joomla по ассоциациям, установка дополнительных языков ещё не делает сайт многоязычным: текст, введённый человеком, переводят люди. Компонент Multilingual Associations показывает контент разных языков рядом, чтобы переводить из одного в другой. Ассоциировать можно статьи и категории, контакты, пункты меню, новостные ленты.

Порядок для Joomla-рецепта:

1. Установить языки RU и EN, создать языковые категории и меню.
2. Создать статью в языке по умолчанию.
3. Открыть «Компоненты → Multilingual Associations», выбрать язык цели и заполнить заголовок и текст перевода.
4. Задать категорию целевого языка и сохранить.
5. Для пункта меню открыть вкладку Associations и создать эквивалент для каждого языка.

Общее правило для обеих сборок: обновление RU-текста не выдаётся за автоматически переведённый EN. Сначала обновляют второй текст или явно сохраняют различие.

Права в WordPress: capabilities и CPT

В документации WordPress роли описаны как набор задач, а capabilities — как отдельные разрешения. Роли предопределены, но capabilities можно добавлять и снимать функциями add_cap() и remove_cap(), а роли — вводить и удалять через add_role() и remove_role().

Ключевое различие — single-site Administrator и network Super Admin. В документации сказано: в случае одиночной установки администраторы фактически являются Super Admin. В Multisite capabilities администратора отличаются, а сетевые возможности — create_sites, delete_sites, manage_network, manage_sites, manage_network_users, manage_network_plugins, manage_network_themes, manage_network_options, upgrade_network, setup_network — доступны только Super Admin. Число предопределённых ролей не объявляем критерием выбора: важны конкретные обязанности.

Для расписания выбран custom post type schedule_item с capability_type=['schedule_item','schedule_items'] и map_meta_cap=true. По документации register_post_type(), capability_type строит capabilities чтения, редактирования и удаления, а массив из двух элементов задаёт единственное и множественное число. map_meta_cap включает внутреннюю обработку мета-capabilities.

В Joomla ACL устроен иначе. По руководству Joomla, часть «кто» настраивается в компоненте Users через группы и уровни доступа, часть «что делает» — в Action Permissions: глобально, в компоненте или в отдельном элементе. Значения глобальных прав переопределяются в правах статей, а те — в правах отдельной статьи. У статьи три действия: Delete, Edit и Edit State.

Проверка прав: положительная и отрицательная

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

Положительная проверка. Вера меняет расписание «Среда 18:00» на «Среда 19:00» и сохраняет разрешённую публикацию. Борис публикует N01.

Отрицательная проверка. Попытка опубликовать N01 от имени Веры должна быть отвергнута сервером. Борис не меняет и не публикует S01. Проверяются обе языковые версии и прямые запросы или ссылки.

Отдельно проверяется наследование. В Joomla все группы наследуют права от Public, у которой нет разрешений ни на какие действия, но элементы Public по умолчанию видны. Другие группы и наследование не должны давать более широкие права, чем задумано. Редакторам не выдают глобальный Super Users.

Проверка языка. С N01 переключатель ведёт к «Enrollment is open», с расписания — к «Wednesday 18:00» или «Wednesday 19:00» после правки. Обновление RU-текста не считается автоматически переведённым EN.

Порядок приёмки для обеих сборок:

1. Войти под Верой, изменить расписание, сохранить публикацию.
2. Под Верой попытаться опубликовать N01 — сервер отклоняет.
3. Войти под Борисом, опубликовать N01, попытаться изменить S01 — сервер отклоняет.
4. Повторить оба шага на RU- и EN-версиях.
5. Проверить переключатель языка на обоих материалах.
6. Проверить прямые URL.

Требования хостинга: WordPress и Joomla 6.x

Текущие требования WordPress.org рекомендуют PHP 8.3, MariaDB 10.11 или выше либо MySQL 8.0 или выше, а также Nginx или Apache с модулем mod_rewrite. Для HTTPS рекомендуется настройка, повышающая безопасность. В примечании указано, что в устаревшем окружении WordPress работает и с PHP 7.4+, и с MySQL 5.5.5+, но эти версии достигли конца жизненного цикла и могут подвергать сайт уязвимостям.

Joomla 6.1 в текущей таблице для 6.x различает три столбца. Для PHP: recommended 8.4, supported 8.3.0, minimum 8.3.0. Для MariaDB: recommended 12.0, supported 10.6, minimum 10.4. Для MySQL: recommended 8.4, supported 8.0.13. Для Apache: recommended 2.4, supported 2.4. Обязательные модули PHP: json, simplexml, dom, zlib, gd, mysqlnd или pdo_mysql или pdo_pgsql. Рекомендуемый модуль — mbstring, рекомендуемый лимит памяти PHP — не менее 256 МБ.

Старая площадка с PHP 8.1 для Joomla 6.x не принимается. Историческую feature page Joomla не используют как доказательство требований Joomla 6. Выбранный хост оценивается по правильному столбцу и совместимости конкретных компонентов.

Что обслуживать в каждой реализации

Счётчик расширений не назначает победителя. Сравниваются конкретные обязанности.

В WordPress-рецепте обслуживаются два сайта и назначение ролей на обоих, собственный CPT и capability-код, ручная карта переводов. Число расширений зависит от выбранной реализации; универсального минимума «два плагина» нет. Допустимы альтернативные multilingual-плагины.

В Joomla-рецепте обслуживаются языковые категории, меню и ассоциации, группы и наследование ACL, обновления CMS и шаблона. Отсутствие дополнительного плагина не отменяет работу по настройке.

Эталон выбора условный. Если уже есть поддерживаемая WordPress-сеть и владелец CPT-кода и ACL, этот рецепт может быть экономнее переноса. Если команда готова сопровождать Joomla-native languages и ACL и проходит те же отказы и пары, выбирают его по совокупности настройки и поддержки.

Перед обновлением сохраняют файлы и базу и проверяют восстановление тестовой копии. Проведённая резервная копия или восстановление не заявляются как выполненное действие.

Частые вопросы

Что выбрать для сайта с двумя языками: WordPress или Joomla?

Обе сборки решают задачу, но по-разному. В WordPress выбранный рецепт — Multisite с двумя языковыми сайтами и ручной картой пар. В Joomla ядро даёт multilingual framework, а переводы создают отдельно через ассоциации. Выбор зависит от того, какую реализацию команда готова сопровождать.

Нужен ли плагин для многоязычного WordPress?

Ядро не делает сайт двуязычным из коробки, поэтому сообщество предлагает плагины. Один из подходов — отдельная установка на каждый язык, в том числе сеть Multisite. Установка языкового пакета сама перевод не создаёт: тексты переводят отдельно.

Чем Administrator отличается от Super Admin?

В одиночной установке администраторы фактически являются Super Admin. В Multisite capabilities администратора ограничены одним сайтом, а сетевые возможности доступны только Super Admin. К ним относятся управление сайтами сети, пользователями, плагинами и темами сети.

Как проверить, что редактор не получил лишних прав?

Проверка двусторонняя. Вера меняет расписание и сохраняет публикацию, но попытка опубликовать N01 от её имени должна быть отвергнута сервером. Борис публикует N01, но не меняет S01. Проверяются обе языковые версии и прямые URL.

Какой PHP нужен для Joomla 6.x и WordPress?

Текущие требования WordPress.org рекомендуют PHP 8.3. Joomla 6.1 в таблице для 6.x указывает recommended 8.4 и supported/minimum 8.3.0. Старая площадка с PHP 8.1 для Joomla 6.x не принимается, а выбранный хост оценивается по правильному столбцу таблицы.