DokuWiki на сервере: частые ошибки и решения

MAATRIX

DokuWiki хвалят за простоту: никакой базы данных, страницы — обычные текстовые файлы в data/pages/, бэкап — это tar каталога. Но именно эта простота порождает свой набор проблем: движок болезненно реагирует на права доступа, кэш иногда живёт своей жизнью, а ACL путают даже опытных админов. Если вы администрируете DokuWiki на своём VPS и упёрлись в белый экран, 403 или сломанные ссылки — ниже разобраны самые частые причины и рабочие решения.

Белый экран и ошибки PHP после установки

Классическая ситуация: DokuWiki установлена, install.php отработал, а при открытии doku.php — пустая белая страница без единого сообщения. Причина почти всегда одна: PHP настроен молчать об ошибках, а вывод падает в лог, который вы не смотрите.

Первым делом включите вывод ошибок временно, чтобы увидеть реальную причину:

# в php.ini или в /etc/php/8.3/fpm/conf.d/99-debug.ini
display_errors = On
error_reporting = E_ALL

После правки перезапустите PHP-FPM и посмотрите, что реально происходит:

sudo systemctl restart php8.3-fpm
tail -f /var/log/nginx/error.log
tail -f /var/log/php8.3-fpm.log

Чаще всего белый экран даёт одна из трёх причин:

• Не хватает расширений PHP. DokuWiki требует минимум php-xml, php-mbstring, php-gd (для миниатюр) и желательно php-zip (для установки плагинов через менеджер). Проверьте: php -m | grep -Ei 'xml|mbstring|gd|zip'.
• Неверная версия PHP. DokuWiki довольно консервативна к новым версиям PHP — на релизах "Kaos" и новее заявлена поддержка PHP 8.1–8.3, но некоторые сторонние плагины ещё используют устаревший синтаксис и падают с fatal error на PHP 8.3. Если плагин критичен, а патча нет — временно держите PHP 8.1.
• Битый local.php после ручного редактирования. Один лишний символ в конфиге, отредактированном руками (а не через admin/config в интерфейсе), рушит весь doku.php. Проверьте синтаксис: php -l conf/local.php.

Отключайте display_errors обратно после отладки — на проде это утечка информации об окружении сервера.

Права доступа: 403, «Permission denied» и незаписываемые каталоги

DokuWiki пишет прямо в файловую систему при каждом сохранении страницы, загрузке файла, изменении конфига через веб-интерфейс. Если владелец каталогов не совпадает с пользователем, от имени которого работает PHP-FPM, вы получите либо явное «Permission denied» в логе, либо тихую невозможность сохранить правки.

Проверьте, каким пользователем реально работает пул PHP-FPM:

ps aux | grep php-fpm
# или посмотрите user = в /etc/php/8.3/fpm/pool.d/www.conf

Дальше — привести владельца записываемых каталогов к этому пользователю (обычно www-data):

cd /var/www/dokuwiki
sudo chown -R www-data:www-data data conf lib/plugins lib/tpl
sudo find data conf -type d -exec chmod 750 {} \;
sudo find data conf -type f -exec chmod 640 {} \;

Важный нюанс: lib/plugins и lib/tpl тоже должны быть записываемыми, если вы ставите плагины и темы через встроенный менеджер, а не вручную по SFTP. Если плагины ставите только вручную — оставьте эти каталоги в режиме чтения с владельцем root, так меньше поверхность атаки.

Отдельная частая ошибка — держать весь /var/www/dokuwiki с правами 777 «чтобы работало». Не делайте так: это открывает дырку для любого другого скомпрометированного процесса на сервере записать в вашу вики произвольный код через загрузку файла. Права 750/640 с правильным владельцем закрывают вопрос без компромиссов по безопасности.

Конфликты .htaccess и настройка Nginx

DokuWiki изначально писалась под Apache и поставляется с готовым .htaccess, который защищает служебные каталоги (data/, conf/, bin/) от прямого веб-доступа. На Nginx этот файл игнорируется — и если не продублировать правила в конфиге сервера, содержимое вики (исходники страниц, включая черновики и историю правок) может оказаться доступно по прямой ссылке.

Рабочий конфиг для Nginx с DokuWiki на PHP-FPM:

server {
    listen 443 ssl http2;
    server_name wiki.example.com;

    root /var/www/dokuwiki;
    index doku.php;

    ssl_certificate     /etc/letsencrypt/live/wiki.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/wiki.example.com/privkey.pem;

    # Закрываем служебные каталоги
    location ~ /(data|conf|bin|inc|vendor)/ {
        deny all;
        return 404;
    }
    location ~ /\.ht {
        deny all;
    }

    # Красивые URL: /wiki/namespace:page вместо doku.php?id=...
    location / {
        try_files $uri $uri/ @dokuwiki;
    }
    location @dokuwiki {
        rewrite ^/(.*) /doku.php?id=$1&$args last;
    }

    location ~ \.php$ {
        include fastcgi_params;
        fastcgi_pass unix:/run/php/php8.3-fpm.sock;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    }
}

После правки не забудьте sudo nginx -t && sudo systemctl reload nginx. Если страницы всё равно открываются старым способом — проверьте, что перезагрузили именно тот конфиг-файл, который реально подключён в nginx.conf через include.

Если вы только настраиваете сервер под DokuWiki с нуля, у нас есть отдельный разбор про настройку Nginx как reverse proxy — многие грабли из него актуальны и здесь, если вика стоит за прокси.

Красивые URL и вечная проблема с rewrite

По умолчанию DokuWiki отдаёт страницы вида doku.php?id=namespace:page — рабочий, но некрасивый и не самый дружелюбный к поисковикам формат. Переключение на «красивые» URL (/namespace:page или /namespace/page) — частый источник 404 после включения.

В админке DokuWiki (admin/config → «URL-адреса») есть три режима:

Самая частая ошибка — переключить режим в админке на «Rewrite», но не добавить соответствующий location @dokuwiki блок в Nginx (он не читает .htaccess, в отличие от Apache). Результат — все внутренние ссылки в вики генерируются в новом красивом формате, но сервер не умеет их раздавать, и пользователь видит сплошные 404. Правило простое: сначала настройте rewrite на сервере, потом переключайте режим URL в самой DokuWiki, а не наоборот.

Медленный поиск и разросшийся индекс

DokuWiki строит полнотекстовый индекс не в базе данных, а в наборе файлов внутри data/index/. На небольших вики (до пары сотен страниц) это летает, но с ростом контента поиск начинает тормозить, а индексация при сохранении страницы подвисает интерфейс.

Несколько практических шагов:

• Проверьте data/meta и data/attic. Каталог attic хранит все версии всех страниц за всю историю — на старой вики с частыми правками он может занимать больше места, чем актуальные страницы. Настройте очистку через $conf['recent_days'], либо чистите вручную раз в квартал.
• Перестройте индекс, если он разъехался. После массового импорта страниц напрямую в data/pages/ (минуя веб-интерфейс) индекс не обновляется автоматически: php bin/indexer.php -c из корня установки.
• Вынесите индексацию в фоновый cron, а не полагайтесь только на индексацию «на лету» — это снимает задержку с обычных посетителей. Подводные камни настройки cron на VPS разобраны в статье про cron-задачи на сервере.
• Проверьте лимиты PHP, если индексатор падает по таймауту: max_execution_time и memory_limit в CLI-режиме (/etc/php/8.3/cli/php.ini) часто оставляют дефолтными.

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

ACL и права пользователей: когда всё «залогинено», но ничего не открывается

Механизм контроля доступа (ACL) в DokuWiki — отдельный источник путаницы, потому что он текстовый (conf/acl.auth.php), правила читаются построчно сверху вниз, и порядок правил имеет значение не так, как многие ожидают: побеждает не первое совпавшее правило, а самое специфичное — правило для конкретной страницы важнее правила для всего пространства имён, даже если оно записано выше или ниже.

Типичная ошибка новичка — открыть доступ на всё пространство имён, а потом добавить более узкое запрещающее правило «для порядка», ожидая что оно применится только к явно перечисленным юзерам, а не переопределит общий доступ для всех остальных.

Формат строки ACL:

# namespace:page    группа-или-юзер    уровень (1=чтение,2=правка,4=создание,8=аплоад,16=удаление)
wiki:*               @ALL               1
wiki:private:*        @admin             16
wiki:private:*        @users             0

Практический совет: не редактируйте acl.auth.php руками вслепую — используйте встроенный менеджер ACL в админке (admin/acl), он визуально показывает эффективное правило для выбранной страницы с учётом наследования. Если ACL всё же правится вручную (например, массово через скрипт), после изменения обязательно проверьте конкретную страницу через «Показать права доступа» в интерфейсе — это единственный надёжный способ убедиться, что итоговое правило совпадает с ожидаемым.

Отдельно — не забывайте, что conf/acl.auth.php содержит структуру доступа к вашей вики и должен попадать в бэкап вместе с data/. Многие теряют настроенные ACL именно потому, что бэкапят только data/pages/, забывая про conf/.

Бэкап и восстановление: используйте простоту DokuWiki по назначению

Отсутствие базы данных — главное практическое преимущество DokuWiki для бэкапа: не нужен mysqldump, достаточно скопировать файлы. Но именно из-за кажущейся простоты бэкапы часто настраивают небрежно — «заберём data когда-нибудь руками» — и теряют историю при первом же серьёзном сбое.

Минимальный набор для полного бэкапа:

#!/bin/bash
# backup-dokuwiki.sh
DATE=$(date +%Y%m%d)
DEST=/backup/dokuwiki
mkdir -p "$DEST"

tar czf "$DEST/dokuwiki-$DATE.tar.gz" \
  -C /var/www/dokuwiki \
  data conf lib/plugins lib/tpl

# храним последние 14 архивов, остальное удаляем
find "$DEST" -name 'dokuwiki-*.tar.gz' -mtime +14 -delete

Обратите внимание: в бэкап обязательно включён conf/ (ACL, конфигурация, ключи API у некоторых плагинов) и lib/plugins, lib/tpl — без них восстановленная вики потеряет все установленные расширения и темы, даже если содержимое страниц цело. Каталог data/cache в бэкап включать не нужно — он пересоздаётся автоматически и только раздувает архив.

Поставьте скрипт в cron и обязательно проверяйте, что архивы реально появляются, а не просто «задача стоит в crontab» — мониторинг выполнения cron-задач через healthchecks-подобные сервисы решает именно эту проблему тихо сломавшихся бэкапов.

Для небольшой вики (до нескольких гигабайт данных) простого tar с ротацией хватает с запасом; переходить на BorgBackup имеет смысл, когда бэкапите сразу несколько сервисов на сервере, а не только вики.

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