Правка фронтенда в ocStore OcStore(OpenCart) 3.0.2. Переделка под свои нужды.

[Триви]

Восстановить его удобный вид не проблема.

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

[laimas]

Ну тогда при таком подходе, по всем css-файлам cleаnCSS-ом прошлись бы.

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

[Триви]

А минимизированные CSS и JS, это тех разработчиков кто действительно позаботился о загрузке только полезного.

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

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

[laimas]

JS-ки за пределами папки кастомной темы не меняются через модификаторы?

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

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

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

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

[Триви]

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

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

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

[laimas]

Представьте, что у вас машина, но где бы вы не ездили на ней, в черте ли города, или в пустыне, вы вынуждены следовать правилам - не выше 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!');
});

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

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

[laimas]

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

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

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

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

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

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

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

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

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

[Vladikslav]

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

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

[laimas]

я всё перепишу как полагается

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

А каков вообще порядок редактирования php-скриптов?

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