Ни в коем случаии вас не критикую только то что мой ГПТ просмотрел:
Вердикт: **идея хорошая, реализация — только как прототип. На боевой DLE 20.0 я бы это не ставил без переписывания.**
Модуль делает простую и полезную вещь: добавляет комментарии к статическим страницам DLE через существующую таблицу `_comments`, подменяя `post_id` на `static_id + 1000000`. Но архитектурно это хак, а не production-ready модуль.
## Что хорошего
Минимальный footprint: в архиве только `static_comments.xml`, без лишних файлов.
Использует DLE VFS, физически ядро не правит.
Идея интеграции с родным `comments.tpl`, `addcomments.tpl`, `navigation.tpl` правильная.
В админке статических страниц добавляется чекбокс “Разрешить комментарии”.
Пытается подключить WYSIWYG/BBCode редактор и стандартный `addcomments.php`.
## Критичные проблемы
### 1. Модуль не под наш текущий стандарт DLE 20.0
В XML стоит:
```xml
<dleversion>19.1</dleversion>
<versioncompare>==</versioncompare>
```
То есть модуль жёстко рассчитан **только на DLE 19.1**. Для нашего текущего baseline это сразу красный флаг. На DLE 20.0 VFS-поиск по точным строкам может просто не примениться.
### 2. Есть bypass прав на добавление комментариев
Самый опасный момент:
```php
if( $is_logged ) {
$user_group[$member_id['user_group']]['allow_addc'] = 1;
}
```
Это принудительно разрешает добавлять комментарии любому авторизованному пользователю, даже если в группе DLE комментарии запрещены. Это нельзя оставлять.
Правильно: **не менять `$user_group`**, а читать реальные права группы и настройки сайта.
### 3. Хак с `post_id = static_id + 1000000`
```php
$news_id = $static_result['id'] + 1000000;
```
Это быстро, но стратегически грязно. Если когда-нибудь ID новостей приблизятся к этому диапазону, появится риск коллизий. Даже если сейчас это маловероятно, архитектура должна быть fail-safe.
Лучше: отдельная таблица связки или отдельная таблица комментариев для static-контекста, либо явный `context_type/context_id`, если переписывать системно.
### 4. Счётчик комментариев будет рассинхронизироваться
Модуль увеличивает `comm_num` только в момент добавления:
```php
UPDATE _static SET comm_num=comm_num+1
```
Но удаление, модерация, approve/unapprove, массовые действия в админке комментариев — не закрыты. Итог: на статике счётчик легко станет неправильным.
### 5. SQL-миграции не идемпотентные
```sql
ALTER TABLE `{prefix}_static` ADD `allow_comments` ...
ALTER TABLE `{prefix}_static` ADD `comm_num` ...
```
При повторной установке/обновлении будет ошибка “Duplicate column”. При удалении — тоже риск, если колонка уже отсутствует.
Нужно делать безопасные миграции через проверку существования колонок.
### 6. Слишком хрупкие VFS-правки
Модуль цепляется к точным строкам в:
```text
engine/inc/static.php
engine/modules/static.php
engine/modules/addcomments.php
engine/inc/options.php
engine/modules/lastcomments.php
engine/classes/comments.class.php
```
Для DLE 20.0 это риск. Любое отличие строки — операция не применится. Особенно опасны вмешательства в `comments.class.php` и `addcomments.php`.
### 7. `addcomments.tpl` парсится неполно
Модуль вручную обрабатывает часть тегов формы комментариев: captcha, recaptcha, question, not-logged, image-upload. Но DLE-шаблон комментариев поддерживает больше условий: подписки, guest-поля, социальные блоки, catlist/not-catlist и т.д.
На реальном шаблоне могут остаться “сырые” теги или сломаться форма.
## Моя оценка
Как идея: **8/10**.
Как текущая реализация: **4/10**.
Как база для нашего production-модуля: **можно использовать только концепт, код лучше переписать.**
## Как бы я сделал под наш стандарт
Оптимальный вариант — не чинить этот XML точечно, а собрать нормальный модуль:
**Static Comments Native v1.0.0 — DLE 20.0 / PHP 8.2+**
Архитектура:
1. В `_static` добавить:
- `allow_comments`
- `comm_num`
2. Все миграции сделать идемпотентными.
3. Не ломать права групп:
- учитывать `allow_addc`
- учитывать CAPTCHA/recaptcha/question
- учитывать модерацию
- учитывать гостевые комментарии
4. Убрать принудительное:
```php
$user_group[$member_id['user_group']]['allow_addc'] = 1;
```
5. Сделать безопасный namespace для static-комментариев:
- либо отдельная таблица `dle_static_comments`
- либо системный адаптер к `_comments`, но с жёсткой защитой от коллизий.
6. Закрыть lifecycle:
- удаление статической страницы → очистка/архивация комментариев
- пересчёт `comm_num`
- очистка orphan-комментариев
- кнопка пересчёта в админке
7. Добавить README и `plugin.xml` notice:
- строки подключения
- совместимость
- ограничения
- быстрый тест
- rollback
## Финальное решение
Я бы **не адаптировал этот модуль “как есть”**. Правильный бизнес-ход — взять идею и переписать под наш baseline. Тогда получим не костыль “комментарии к статике”, а нормальный DLE 20.0-модуль, который можно дальше расширять: рейтинг комментариев, AI-ответы, уведомления, SEO-блоки, последние комментарии по статике.
Главные особенности плагина:
Установка и использование:
️ Важное обновление: Интеграция с общими комментариями
Раньше: Комментарии со статических страниц были строго изолированы и намеренно скрывались из глобальных списков (таких как последние комментарии, профиль пользователя и тег {customcomments}), чтобы избежать появления нерабочих битых ссылок вида 1000000.html.
