Ну тогда при таком подходе, по всем css-файлам cleаnCSS-ом прошлись бы. Восстановить то не проблема :)
Хорошо что JS не аглифицирован, такой точно в удобоваримый формат не переведёшь :)
Ладно холивар уже пошёл ))) Фиг с ним, не суть )

Насколько мне известно в Opencart подвергаются минимизации только встроенные в шаблоны js сценарии, да и лучше бы оно вообще не делалось ибо курам на смех. Всем иным в базовой поставке CMS не занимается. А минимизированные CSS и JS, это тех разработчиков кто действительно позаботился о загрузке только полезного.

Не стал я настраивать Gulp или Webpack для проекта. Честно говоря, не очень представляю как в таких проектах правильно организовать `src` и `dist`. В принципе можно в директории `theme` сделать две папки типа `mytheme-src` и `mytheme-dist`, первую и отслеживать, но ведь править приходится некоторые вещи за пределами папки с моей темой, хотя конечно 95% всех правок производится в ней. Хотя и тут можно что-то придумать.

Я не совсем понял. JS-ки за пределами папки кастомной темы не меняются через модификаторы? Просто там на старом синтаксисе ES5 всё написано. Я уже стал от него отвыкать. В новом с вебпаком всё так здорово - подключил файл, расширил класс. А тут... Как мне в своём кастомном js-файле например расширить с добавлением новых свойств и методов класс псевдокласс `cart`, построенный по-старинке на объекте?

Встроенные в шаблоны js-сценарии компилируются шаблонизатором и это нужно учитывать. Если бы в этих сценариях существовала хотя бы какая либо договоренность, тогда бы был порядок и было бы легче найти/добавить/заменить модификатором. Попробуйте найти модификатором фрагмент js-кода, без танца с бубном и рег. выражений не получится.

Собственно насиловать код и не нужно для этого. Код модификатора можно взять из файла modification.php, чуточку подправить чтобы обрабатывал один файл/один модификатор, и результат выводил на экран - лог, и пропущенный через htmlspecialcahrs() результат. Вот на этом и тренируйтесь для уяснения где вы ошибаетесь в ожиданиях.

А в базовой поставке из подключаемых файлов (не считаем плагины) всего один - common.js, в котором не так и много кода, обработчик поиска да корзины. Его проще заменить через модификатор на свой. Например так поступают при добавлении новых модулей/расширений/тем, помещая его новую версию в отличный от базового каталог.

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

Да, договорённостей тут не очень. Приходится постоянно отслеживать селекторы во время внедрения другого дизайна. Я переписал их так: $('#самыйВерхнийРодительВсе гоШаблона #элемент(или .элемент) ').actionts...
а то встречаются выборки по более низкоуровневым родителям. Ну их.. всё скопом хватаю. Ошибок пока нет.

Если каждый модуль внедряет свои модификаторы, т.е. один произвёл один замены в исходниках, другой другие, то тогда как они вообще потом вместе уживаются? Если они предполагают js-код, то как этот код вообще будет обращаться к моим элементам, моей вёрстки? Вопросов больше чем ответов.

Короче, чувствую, что большие проблемы начнутся, когда я начну ставить модули. Нахер я вообще за это взялся :cray:

Представьте, что у вас машина, но где бы вы не ездили на ней, в черте ли города, или в пустыне, вы вынуждены следовать правилам - не выше 40 км/час, 15 км прямо, затем налево 20 км, ... Нафиг оно нужно такое авто. Вот так и с CMS, кому-то нравится "ездить в их рамках" постоянно, а мне нет, надоела вся эта хрень, тупеешь. Но бывает, что выполняю такую работу, сейчас как раз выполняю связанную с Opencart.

Эта CMS заточена под торговлю, все ли в ней сделано для этого на 100%, это вопрос риторический. Но она в базовом варианте предоставляет инструментарий который как минимум позволяет торговать всем. Но всю номенклатуру товаров нельзя поставить в один ряд. Например, бытовой прибор, он может иметь вид спереди, справа, слева, ..., то есть иметь множество изображений продукта.

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

Было предложено, уж коли карусель изображений, то это изображения категории, которой принадлежит продукт, по которым можно было бы переходить и в карточку продукта. После у заказчика возник вопрос возможности добавления слайдера к этой карусели. Окончательный вариант - в слайдере подписи, не у текущего продукта, это ссылка на карточку.

Выбранный заказчиком слайдер Fresco имеет баг - можно сколь угодно передавать в него изображения для эскиза, он все равно будет их готовить из больших изображений. Но в случае с данными продуктами, этого никак нельзя. Пришлось лезть в код слайдера, искать и править. Но это уж точно никак не повлияет на будущие обновления/добавления. В базовом контроллере продукта произведена модификация, а вот модификация шаблона уже не базового, а используемого расширения. В шаблоне вырезаны подключения скрипта, а также его вызов, который приводил к ошибке на странице, работал не везде, и как оказалось заказчику вообще не нужен.

Вообще расширение написано настолько криво, не в плане не грамотно, а в плане логики. Почему-то не подумали (или не хотели) о SVG, когда решали задачу описания и добавления вариантов выбора модификаций изображения продукта. Все описывается в виде массивов координат с вытекающими отсюда неудобствами, чтобы добавить что-то новое, придется править код в common.js ручками, ибо искать и править модификатором будет весьма затруднительно, что и не предусмотрено через админку.

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

Естественно все что правилось, все через модификаторы. А один и тот же файл могут модифицировать множество разработчиков своими файлами модификации. Модификатор собирает все это воедино. Для того чтобы избежать конфликтов, нужно выполнять модификацию в определенном порядке, для этого есть уже и модуль OCMOD Order.

Если делать, то делать, а абы как, это не дело, я так думаю. Мне не понятны на сайтах вещи лишенные смысла, я увидел такое, если бы на вопрос "что за ..." заказчик бы ответил "да и ... с ним", то бы и работа давно закончилась. Но коли и он озадачился, и решено было довести до какого либо смысла, значит нужно делать так, чтобы работа была не в тягость, а когда она не в тягость, это интересная работа. ;)

SVG вообще по умолчанию не разрешены в opencart.
Я решил эту проблему вот так.

А откуда берется вот это? -

{% for script in scripts %}
<script src="{{ script }}" type="text/javascript"></script>
{% endfor %}

А то я подключил ещё в начале свои скрипты в хэдере вот таким образом:
<script src="catalog/view/javascript/custom.js" type="text/javascript"></script>

Ну и расширяю скрипты из коробки типа так:

$(document).ready(function() {
	cart.add3 = function(mess) {
		alert(mess);
	}
	cart.add3('Yo!');
});

смысл понятен :)

Может не так делаю? )

Пофигу, этого в данном случае и не требуется, они будут загружаться не как картинки через файловый менеджер, а как файлы и храниться как текст в базе. В движке многого чего нет по умолчанию, взять тот же разводимый им мусор из картинок при смене их у продукта или удалении продукта. Не хватало чтобы он еще и мусорил SVG.

Из данных переданных в шаблон в контроллере шапки страницы

$data['scripts'] = $this->document->getScripts('header');

Это метод класса Document, он же имеет и метод добавления своих скриптов, которые добавляются в том или ином контроллере (это помимо явно прописанных в шаблонах):

$this->document->addScript(путь->имя скрипта, куда помещать, по умолчанию в шапку);

Их и собирает метод getScripts, а то что вы делаете, это явно прописанные, только чтобы их кто-то не снес, это надо делать через модификатор.

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

И всё таки, после того, как возьму проект на поддержку, я всё перепишу как полагается. Убью пару тройку дней, но сделаю.

А каков вообще порядок редактирования php-скриптов? Используя сразу файл модификатора, особо не натестируешься. При разработке правишь исходник, потом возвращаешь забэкапенный, сравниваешь и составляешь таким образом модификатор?

Все, тогда уж свой движок писать используя какой либо фреймворк.

Порядок по приоритету, не станете же вы первым делом править шаблон, если контроллер не отдает ему данные необходимые, и изменять контроллер если модель не обладает нужными методами. А вот способ обычный - берется исходный файл, если он изменен ранее и кеширован, значит из кеша и дополняем/изменяем и т.п. его код. А после отладки изменения/дополнения описываем в модификаторе, удалив все свои правки из исходника. После применения модификатора они будет вставлены в файл.