Представьте, что у вас машина, но где бы вы не ездили на ней, в черте ли города, или в пустыне, вы вынуждены следовать правилам - не выше 40 км/час, 15 км прямо, затем налево 20 км, ... Нафиг оно нужно такое авто. Вот так и с CMS, кому-то нравится "ездить в их рамках" постоянно, а мне нет, надоела вся эта хрень, тупеешь. Но бывает, что выполняю такую работу, сейчас как раз выполняю связанную с Opencart.
Эта CMS заточена под торговлю, все ли в ней сделано для этого на 100%, это вопрос риторический. Но она в базовом варианте предоставляет инструментарий который как минимум позволяет торговать всем. Но всю номенклатуру товаров нельзя поставить в один ряд. Например, бытовой прибор, он может иметь вид спереди, справа, слева, ..., то есть иметь множество изображений продукта.
Я думал, когда попросили сделать, что это будет езда на "автомобиле по условиям" на дистанцию не более 100 метров, ибо требовался пустяк - автоматически выбирать в карусели изображений продукта иное по умолчанию изображение. Выбор это тоже карусель, с различными способами модификации выбранного изображения. Можно было бы сделать что просят и забыть, но продукты этого магазина могут иметь только одно изображение, нет у них вида слева, справа, ... Естественно встал вопрос, зачем тогда карусель изображений, с которой нужно бороться костылями, хотя это должен был сделать разработчик расширения обеспечивающий работу с этими продуктами, заблокировав вывод ну хотя бы в шаблоне продукта, а по уму так и в контроллере нечего этим заниматься. А пользователь добавил в карусель изображения, которые к продукту вообще не имеют отношения, в админке то доступно, вот и ...
Было предложено, уж коли карусель изображений, то это изображения категории, которой принадлежит продукт, по которым можно было бы переходить и в карточку продукта. После у заказчика возник вопрос возможности добавления слайдера к этой карусели. Окончательный вариант - в слайдере подписи, не у текущего продукта, это ссылка на карточку.
Выбранный заказчиком слайдер Fresco имеет баг - можно сколь угодно передавать в него изображения для эскиза, он все равно будет их готовить из больших изображений. Но в случае с данными продуктами, этого никак нельзя. Пришлось лезть в код слайдера, искать и править. Но это уж точно никак не повлияет на будущие обновления/добавления. В базовом контроллере продукта произведена модификация, а вот модификация шаблона уже не базового, а используемого расширения. В шаблоне вырезаны подключения скрипта, а также его вызов, который приводил к ошибке на странице, работал не везде, и как оказалось заказчику вообще не нужен.
Вообще расширение написано настолько криво, не в плане не грамотно, а в плане логики. Почему-то не подумали (или не хотели) о SVG, когда решали задачу описания и добавления вариантов выбора модификаций изображения продукта. Все описывается в виде массивов координат с вытекающими отсюда неудобствами, чтобы добавить что-то новое, придется править код в common.js ручками, ибо искать и править модификатором будет весьма затруднительно, что и не предусмотрено через админку.
Вот так, удаляя один костыль из расширения, возникает вопрос о другом. Ну сейчас вроде бы все костыли устранены, сделано по уму, теперь нужно сделать большое, но удобное - вместо массивов координат SVG.
Естественно все что правилось, все через модификаторы. А один и тот же файл могут модифицировать множество разработчиков своими файлами модификации. Модификатор собирает все это воедино. Для того чтобы избежать конфликтов, нужно выполнять модификацию в определенном порядке, для этого есть уже и модуль OCMOD Order.
|
Сообщение от Триви
|
|
Нахер я вообще за это взялся
|
Если делать, то делать, а абы как, это не дело, я так думаю. Мне не понятны на сайтах вещи лишенные смысла, я увидел такое, если бы на вопрос "что за ..." заказчик бы ответил "да и ... с ним", то бы и работа давно закончилась. Но коли и он озадачился, и решено было довести до какого либо смысла, значит нужно делать так, чтобы работа была не в тягость, а когда она не в тягость, это интересная работа.
