Собственные разработки и дальнейшая участь таких поделок

Спасибо за внимание!
В общем смотрите есть некоторое количество проблем, которые не победить без поддержки разработчиков. Итак по порядку.

1. Кастомизация НЕРНР файлов.
Для удобства установки расширений как собственно и для поделиться добавили классную штуку "Темы" куда складываются доработанные файлы. Для того чтобы создать интерфейс управления модулем порой необходимо добавить стили в файл adm/css/main.css
Что из этого следует? Перенести только файл в <тема>/adm/css/main.css недостаточно едет вся админка чтобы сохранить красоту требуется переносить папку adm полностью, чтобы находились компоненты указанные в путях кастомизируемого CSS файла.
Ещё один пример есть файл js/site.js этот скриптик выполняет очень много важной работы, например помогает доставить информацию заполненной формы в СМS и вернуть ответ пользователю. На тех или иных участках необходимо выполнять небольшие задачки, например отправка сигналов различным системам типа Яндекс Метрики, Гугол аналитики.
Предположим есть 2 модуля которые требуют модернизации данного файла первый то установится без проблем, а второй уже придется интегрировать в ручном режиме. Здесь же и возникает ещё одна проблема допустим нашли какую то багу и чтобы её исправить потребовалось вмешательство в том числе и в js/site.js итог после обновления на сайте что-то не нажимается.

2. Кастомизация ядерных файлов. Замечательно что теперь можно это делать. Очень высокий шанс того, что при каждом следующем обновлении эти ядерные файлы будут изменены. Соответственно при решении задач, если требуется организовать какую-то полезную возможность, которая может пригодится не только для текущего решения конкретной проблемы, можно обратиться в тех поддержку с просьбой добавить пару строк. И опять проблема когда они будут добавлены? Далее в 90% случаев не достаточно вставить собственный код в начало или в конец метода, по причине в начале обрабатывать ещё нечего, а в конце уже поздно что либо обрабатывать, потому как всё уже улетело на пк пользователя. Вот и приходится переопределять Методы полностью. Что из этого вытекает 9 к десяти что сайт после обновления ляжет полностью. Выходы: после каждого обновления проверять нужные системные файлы и допиливать по необходимости, чтобы такой модуль корректно работал в актуальной версии или же забыть про обновления и разрабатывать модуль в замороженой версии СМS и использовать эту версию для создания сайтов клиентам и в дальнейшем также не обновлять. Вариант 2 это путь боли и грусти, как говориться даже не вариант. Да и касаемо первого пути. Разработка ведётся на рабочей машине, а не на каком-то рабочем сайте. Так уж сложилось нельзя обновлять СМS на машине на которой работаешь обязательно нужно иметь тестовую копию в сети чтобы появилась такая возможность, вот и приходится гонять туда сюда обратно. Кароче тоже головняк ещё тот. Вот и получается, что такого рода серьёзные решения, никогда не будут представлены в Магазине дополнений потому, что публиковать там такое решение, которое не будет работать у 99.(9)% пользователей не имеет никаго здравого смысла. Будут только упрёки и тонны фекалий: Я поставил ваш модуль и у меня сайт упал совсем. Я поставил ваш модуль и теперь обновится не могу в вашем модуле тонна ошибок куда смотрит команда Diafan если позволяет таким решениям быть в аддонсах.

Как-то так.

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

Ещё раз спасибо за внимание тем кто дочитал. Жду ответы (умозаключения по изложеным проблемам) партнёров и особенно разработчиков Diafan.CMS

Проблем с кастомизацией ещё много. Потребовалось подправить файл - "prettyPhoto.css", в результате, система восстановила оригинальный файл, а изменённый запихнула в папку темы.Всё бы хорошо, ведь, как пишут в документации, кастомные файлы имееют преимущества, но .. В файле " hemesfunctionsshow_head.php", если я правильно понял, "prettyPhoto.css" подключается только в корне сайта, без проверки на наличие кастомного файла.
Получается, после обновления - править файл снова!

Добавлю от себя. Добавленные файлы и папки из корня сайта не переносятся в созданную тему. Добавил я, например, несколько фавиконов для разных устройств и обслуживающие файлы к ним, в корне получается уже немного каша. И вычленять это всё при переносе темы на другую CMS трудоёмко. Создал в корне папку с файлами шрифтов - она тоже никуда не переезжает при генерации темы.

На мой взгляд в аддонсах не хватает указаний на версию cms.diafan, на которой безошибочно работает дополнение. Например, мне периодически приходится отслеживать изменения в cms, затем корректировать дополнения и отправлять их на модерацию. Соответственно доступное для скачивания дополнение работает с новейшей версией cms, но с прошлыми версиями уже может не работать. Так вот предложение, чтобы в аддонсах была возможность привязывать версии дополнений к версиям cms.diafan. Т.е. пользователь не обновляет свой cms по каким-то причинам, заходит в аддонсах и скачивает версию дополнения, которое соответствует версии его cms.
Думаю таким образом можно было бы снять ряд недопониманий со стороны клиентов.

Одновременно хотел бы отметить следующее. Так как обновление дополнений требует некоторых усилий и временных затрат, то, на мой взгляд все же нужен некий стимул. Т.е. если клиент скачал одну версию дополнения, то скачивание последующих обновлений такого дополнения было бы за условно символическую плату. Допустим 10% от стоимости такого дополнения. Сумма - не принципиальна, а вот само это действо все же стимулировало бы авторов дополнений.

Уточню. Это всего лишь мои мысли в слух. Интересно и Ваше мнение.

Сейчас попробую призвать сюда разработчиков или главного архитектора нашей матрицы. Ато агент Виталий не отметился в данной теме.

Я не самый зверь в супер-программировании, это надо Марину призывать в топик. А Марина пространственно рассусоливать не будет Ей вот эти не предметные фразы не скажут ничего: . Она спросит "Дайте конкретную задачу и проблему, мы скажем/подскажем, как лучше её решить. А если есть загвоздка в ядре, поправим ядро".
Еще одну реплику приведу, проявляющую истинную проблему:

Так вот, это не проблема кастомизации! Это проблема неиспользования кастомизации! Конечно, если файл стилей подключен напрямую, система увидит, что файл новый и перекинет его в кастом, но как система узнает, как это файл был подключен и на каком основании она будет править пути?
Здесь все просто: с учетом тем и кастомизации работает тег

В этом случае, если поправить style.css, при обновлении исходный восстановится, правленный перекинется в папку темы, а система поймет, что в теме есть кастомизированный файл и подключит именно его.
Или надо использовать PATH в скриптах или <insert name=path> в шаблонах, они тоже путь делают правильный, в зависимости от того, есть ли кастомный файл или нет.
Т.е. решить вопрос с prettyPhoto.css очень просто: поправили сам файл, поправьте также и путь к нему, заменив относительный / на path и всё.

Виталий говорит про модули, а не шаблоны. У нас шаблоны самые старые конца 2014 года и они работают сейчас, в середине 2016, без доработок.

В случае с программным модулями, затрагивающими ядро, ситуация сложнее, конечно, но тут тоже вопрос только использования кастомизации. В частности, я бы придерживался идеи как можно меньше затрагивать системного, если возможно. Например
- зачем? В своем модуле подключите другой CSS, и положите его в папку своего модуля в тему. Просто переопределите в нем нужные системные стили, добавьте свои и все. Исходный файл не тронут, задача выполнена.
То же самое, но говорить лучше предметно. Какие именно сигналы нужно отправлять, откуда, из какого модуля, как именно отправлять и т.д. Я уверен, задачу можно решить соседним JS-файлом, без правки системного.
Чуть сложнее с РНР-файлами ядра, но есть их частичная кастомизация, кода мы так же не трогаем исходный файл, а переопределяем и добавляем новый функционал через new или replace. Для этого они и сделаны, чтобы не трогать исходный файл и не зависеть от обновлений.
Это и есть та самая "платформа для изоляции таких модулей, чтобы они могли работать всегда и вездее не зависимо от внутренних изменений CMS и фундаментальных модулей."
Это вообще не вариант.

Однако, здравствуйте. Почитал, и подумал, что можно написать про это тут. Я решил привинтить в мобильную версию сайта http://sunnydogspb.ru/m свайпбокс http://brutaldesign.github.io/swipebox/, дабы распознавались нативные жесты, вместо Преттифото. Реализовываться это должно было через правку кода в файле \modules\images\js\images.editor.js путем замены в строке 257

на

с прописыванием в head соответствующих ссылок на CSS и JS.
На локалхосте все работает как надо, а при выгрузке в сеть images.editor.js почему-то не работает по-новому, и все равно генерирует ссылку без указания класса.
Кто знает, в чем дело?

Другие папки в Кастоме есть?
- Там поищи файлы "Дальнейших Издевательств" =)))

претти, кстати, распознает жесты с тачскринов. Там доп.файл pretty.swipe.js (как-то так он там называется, не помню точно, пишу с телефона) надо просто подрубить.