Помощь DLE и "вайбкодинг"

[Numpadd]

Всем привет, хотел поднять такую тему, очень много лет назад создал сайт на dle 13.2, сайт все время работал. И вот пришло время обновится. Соответственно, модули, все правки движка отлетают. Я даже уже не особо помню что там делал. Ну даже это опустим, некоторые модули вообще надо переделать, и вот возникла ситуация, если просто воспользоваться Codex, какие могут быть риски, проблемы и так далее, при написании модуля оплаты и так далее? Поделитесь опытом, чтобы все это я, да и может кому понадобится, могли учти это при разработке

 

[kaster1980]

При переносе старого DLE 13.2 на актуальную версию и переписывании собственных модулей, Codex использовать вполне разумно. Но модуль оплаты — как раз тот случай, где нельзя ограничиваться схемой «Codex написал → залил на сайт». Основные риски здесь не столько в том, что ИИ напишет синтаксически плохой PHP. Код может выглядеть отлично и нормально работать, но иметь ошибку именно в бизнес-логике оплаты.
Например, могут быть критичны ситуации:
- пользователь может подменить сумму заказа;
- статус paid устанавливается после возврата пользователя с платёжной страницы, а не после проверенного серверного callback/webhook;
- подпись webhook проверяется неправильно;
- один callback можно отправить несколько раз и несколько раз начислить баланс;
- order_id можно подменить;
- сумма и валюта из callback не сверяются с созданным заказом в вашей БД;
- секретный ключ оказывается в PHP-файле, Git или логах;
- Codex может использовать устаревшую версию API платёжной системы и т.д.

Как бы я делал обновление старого DLE.
Я бы вообще не начинал с переписывания модулей. Сначала сделал полную копию старого сайта:
DLE 13.2 + БД + uploads + шаблоны + все собственные PHP-файлы.
Затем положил исходный чистый DLE 13.2 рядом с вашей рабочей версией и поручил Codex провести сравнение:
Найди все отличия этой установки от оригинального DLE 13.2.
Не изменяй файлы.
Раздели изменения на:
1. модификации ядра DLE;
2. сторонние модули;
3. изменения шаблона;
4. изменения БД;
5. неизвестные изменения.
Для каждого изменения запросил бы объяснение его предполагаемого назначения. Вот здесь Codex может быть особенно полезен. Он способен исследовать незнакомый код, прослеживать связи между компонентами и объяснить существующую архитектуру. Это как раз один из сценариев, для которых его как раз таки и стоит использовать.
Ну а далее уже "копал" в сторону обновления самого движка и написания модуля оплаты и т.д.

 

[Numpadd]

При переносе старого DLE 13.2 на актуальную версию и переписывании собственных модулей, Codex использовать вполне разумно. Но модуль оплаты — как раз тот случай, где нельзя ограничиваться схемой «Codex написал → залил на сайт». Основные риски здесь не столько в том, что ИИ напишет синтаксически плохой PHP. Код может выглядеть отлично и нормально работать, но иметь ошибку именно в бизнес-логике оплаты.
Например, могут быть критичны ситуации:
- пользователь может подменить сумму заказа;
- статус paid устанавливается после возврата пользователя с платёжной страницы, а не после проверенного серверного callback/webhook;
- подпись webhook проверяется неправильно;
- один callback можно отправить несколько раз и несколько раз начислить баланс;
- order_id можно подменить;
- сумма и валюта из callback не сверяются с созданным заказом в вашей БД;
- секретный ключ оказывается в PHP-файле, Git или логах;
- Codex может использовать устаревшую версию API платёжной системы и т.д.

Как бы я делал обновление старого DLE.
Я бы вообще не начинал с переписывания модулей. Сначала сделал полную копию старого сайта:
DLE 13.2 + БД + uploads + шаблоны + все собственные PHP-файлы.
Затем положил исходный чистый DLE 13.2 рядом с вашей рабочей версией и поручил Codex провести сравнение:
Найди все отличия этой установки от оригинального DLE 13.2.
Не изменяй файлы.
Раздели изменения на:
1. модификации ядра DLE;
2. сторонние модули;
3. изменения шаблона;
4. изменения БД;
5. неизвестные изменения.
Для каждого изменения запросил бы объяснение его предполагаемого назначения. Вот здесь Codex может быть особенно полезен. Он способен исследовать незнакомый код, прослеживать связи между компонентами и объяснить существующую архитектуру. Это как раз один из сценариев, для которых его как раз таки и стоит использовать.
Ну а далее уже "копал" в сторону обновления самого движка и написания модуля оплаты и т.д.

Бро это же ии написало, он и так это все знает перед задачей ахаха

 

[CHADREX]

В первую очередь лучше подготовить удобную среду для тестирования и ловли ошибок, например локальный openserver.
Потом накатить чистый двиг на новую архитетуру (php/sql).
Старые модули, или их установочные билда лучше положить в отдельную папку рядом (например /dev/ в корне.

А дальше запрос, чтобы оно проанализировало то как работают компоненты новой версии движка, затем сопоставило возможность работы старого модуля с учетом php 8.5, а дальше именно создало с нуля модуль на базе старого, не переписать/поправить, а именно с нуля. Так оно пройдет по всем связям и сможет отловить потенциальные ошибки.

 

[88788]

Да, можно и да же нужно. Я вас понимаю, как это лениво в ручную старые проекты обновлять. Раньше не было выхода, работали только руками, а сейчас есть ии.

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

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

Вот тут админ в публиковал в разделе Халява триальную подписку Gitlab, там можно получить доступ на GPT-6 Astra и Claude Fable.

На своем опыте, я скажу, так что Codex с шаблонами, с фронтенд-задачами работает лучше, чем Claude, а код лучше пишет клауд.
Но это не утверждение единственно верное, у вас все может быть по другому, это может зависеть от постановки задачи, т.е. от промпта на задачу.