KS Developer - подсказывает как называется файл кеша измененный системой плагинов DLE

Но ZIP я бы в production в таком виде не ставил
Я нашёл несколько вещей, которые стоит сначала исправить.

1. Остался явно чужой кусок кода:

 
if($_SERVER["REQUEST_METHOD"] == "POST")
    include_once (
        DLEPlugins::Check(
            ENGINE_DIR . '/inc/kylshop/action.php'
        )
    );
 
kylshop вообще не относится к KS Developer, и такого файла в архиве нет.

Очень похоже на copy-paste из другого модуля. Это нужно удалить полностью.

2. user_hash захардкожен:

 
<input type="hidden"
       name="user_hash"
       value="7c9acf61bf316abbb3e6321aa9122968ceceb623">
 
Так делать нельзя. Если токен вообще нужен, он должен приходить из текущей DLE-сессии, а не быть записан в исходник.

Хотя здесь форма практически ничего не отправляет, сам паттерн неправильный.

3. Более неприятная ошибка находится в jаvascript.

Кнопка «Очистить цвета» делает:

 
localStorage.clear()
 
А это очищает не данные KS Developer, а весь localStorage текущего домена.

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

Правильно было бы хранить:

 
ksdev:file:engine/modules/show.full.php
ksdev:file:engine/inc/addnews.php
 
и удалять только ключи с ksdev:.

Для нашего сайта это как раз класс риска совместимости с уже установленными модулями, который мы отдельно контролируем.

4. plugin.xml рассчитан на диапазон:

 
<dleversion>19.0</dleversion>
<versioncompare>greater</versioncompare>
 
В DLE это фактически означает >= 19.0.

Для обычного публичного плагина это понятно, но для нашего production-контура мы приняли другой стандарт:

 
<dleversion>21.0</dleversion>
<versioncompare>==</versioncompare>
 
поскольку сертифицируем модули именно под проверенное ядро DLE 21.0.

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