Bogdan1975

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

Добрый день, @freelancer Есть какая-нибудь схема работы с разработчиками? Вопрос преимущественно в кодировке ioncube: - как с одним проектом работать в нескольких окружениях (локально, dev, pre-prod, prod)? - какая часть кодируется, остается ли свобода на "допил"? Заранее благодарен.

В первом посту сейчас: Если мне не изменяет память оба пункта выполнены (ну 1 так точно), осталось реквесты принять и ... выпускать релиз :eek: 2 freelancer: это не разрешение, это предвкушение ;)

Уже не нужна такая мера. Расковырял seo_pro.php, теперь он отрабатывает и на Ajax и на iframe Вот сообщение с модернизированным seo_pro.php

Присутсвие "-" считаю не критичным, поэтому убрал их вырезание, а пробелы считаю лишними, поэтому их вырезание оставил. Что с чем не вяжется? Ой, ну не надо быть таким строгим. Вы же не экзамен по программированию принимаете. А копипаст breadcrumbs в каждой вьюхе - это признак высокого стиля? OpenCart в целом не безгрешен. Вот, честно, не понимаю я Вашего подхода - из-за "говнокода" (который подправить - 2 сек) Вы отвергаете решение проблемы "говнологики". Ну ладно бы просто заметить, что не мешало бы исправить, а то сразу объявить никчемным бредом, назвать статью вредной и т.д. Между прочим, кроме этих ребят никто и не заметил этого лага ... Т.е. по Вашему все же из-за ненавистного Вам !$n пусть кеш отдает инфу из файлов, которые нужно сносить ...? По-моему это намного больший "бред", чем шалость в виде !$n. Ну а если так скурпулезно подходить, то в OpenCart нужно многое почеркать, скомкать и в ... Опять же зачем все сносить, если можно поменять strtolower(trim(preg_replace('~[^0-9a-z\.]+~i', '-', html_entity_decode(preg_replace('~&([a-z]{1,2})(?:acute|cedil|circ|grave|lig|orn|ring|slash|th|tilde|uml);~i', '$1', htmlentities($string, ENT_QUOTES, 'UTF-8')), ENT_QUOTES, 'UTF-8')), '-')); на strtolower(trim(preg_replace('~[^0-9a-z\.\/]+~i', '-', html_entity_decode(preg_replace('~&([a-z]{1,2})(?:acute|cedil|circ|grave|lig|orn|ring|slash|th|tilde|uml);~i', '$1', htmlentities($string, ENT_QUOTES, 'UTF-8')), ENT_QUOTES, 'UTF-8'))));

Согласен, но на работоспособность это не влияет, ибо в этом цикле $n никода не будет ни null ни false ни пустой строкой. Не согласен в корне! Раз кеш "состарился", то пусть данные берутся из первоисточника, иначе логика совсем нарушается - кеш свое отжил, ну и Бог с ним, все равно будем оттуда черпать информацию ... Потом сразу же его прибьем, но хоть последний разочек возьмем ... Кстати, забыл указать, что я там к функции set добавил третий необязательный параметр времени жизни кеша. Если отсутствует, то будет дефолтным. Я именно это и утверждал. Так ведь никем пока не предложено нормальное решение, без "дырок". Разве это выход - убрать недостаточный контроль и ничем его не заменить?

Посчитал (и сейчас считаю), что пробелов быть не должно, а "-" не сильно помешают. Что касается самих имен файлов - тут не взял на себя смелость менять их формат, т.к. не знаю чем было вызвано их приведение к текущему виду. А с чего Вы взяли, что не посмотрел...? Отличное решение! По-моему следовало бы проблему переформулировать: заменить точку контроля имен файлов. Не уверен, что правильно совсем убирать "неправильный" контроль, не имея другого.

А что тут бредового ...? В статье говорится, что этим кодом исправляется тот момент, что в оригинальной функции данные берутся из файла до проверки его временной актуальности. Так и есть, измененный код берет после проверки из самого свежего файла только в случае если он не "просрочен". А по поводу обращений к кешу - согласен, нужно выделить время и пройтись по моделям, исправить проверки на null

Pull-request на эту тему уже отправлен by Alexey. Если примут, то всё будет нормально

Сделано. Pull: https://github.com/myopencart/ocStore/pull/31/files

Меняем файл catalog/model/tool/image.php на приложенный, и проблема решается проблема решается неправильно, смотрим https://opencartforum.com/topic/27002-%D0%BF%D1%80%D0%BE%D1%86%D0%B5%D1%81%D1%81-%D1%80%D0%B0%D0%B1%D0%BE%D1%82-%D0%BD%D0%B0%D0%B4-%D1%80%D0%B5%D0%BB%D0%B8%D0%B7%D0%BE%D0%BC-ocstore-15512/?do=findComment&comment=220044 image.php

В 1.5.4.1 категории забирались из модели, формировался массив $categories, затем этот массив сортировался рекурсивной функцией getAllCategories(); $this->data['categories'] = $this->getAllCategories($categories); В 1.5.5.1.1 этой сортировки уже не было, было просто $this->data['categories'] = $this->model_catalog_category->getCategories(0); Собственно, я и предложил сортировать рекурсивной функцией, которая как я увидел позже просто делает примерно тоже самое, что функция в getAllCategories() в версии 1.5.4.1 А затем увидел, что в мастер версии использование getAllCategories() восстановлено, правда позже результат затирается строкой $this->data['categories'] = $this->model_catalog_category->getCategories(0); Поэтому и говорю, что решение сводится к удалению этой строки из мастер-версии

Блиииин .... Чего ж я сразу не глянул! Alexey, гляньте на сборку ocStore 1.5.4.1 - тогда было "общепринято" сортировать рекурсивно!!! А мы тут спорим ... Нам с Вами должно быть стыдно, причем Вам - вдойне :) (шутка) В 1.5.4.1 все нормально сортировалось (рекурсивно, кстати, а не как принято) В 1.5.5.1.1 ничего этого уже нет, рекурсивная функция отсутствует, категории забираются скопом и без сортировки отдаются в мир. В мастер-версии все восстановленно, но одна строчка все портит. А по сему, изобретенные мною с Вами велосипеды нужно выкинуть на помойку (а лучше сжечь), а вместо этого в мастер-версии фрагмент: // Categories $this->load->model('catalog/category'); $this->data['categories'] = $this->model_catalog_category->getCategories(0); нужно отправить вслед за велосипедами. Хотя нет .... "// Categories" нужно оставить :) Спешка и невнимательность - вот причины, по которым мы с Вами тут холиварить начали

А потом у меня появится еще 1 товарная группа (главная категория), и мне нужно чтобы она была между 100 и 200. Как быть? У меня сортировка внутри категории/подкатегории выглядит как 10, 20, 30 и т.д. И не для того чтобы дочерним назначать 11, 12; 21, 22, а для того, что бы была возможность безболезненно вставлять категории внутри уровня. Не думаю, что я такой "эксклюзивный", возможно, часть пользователей нумеруют по такому же принципу. Т.е. безструктурная сортировка фактически обязывает нумеровать по принципу, используемым Вами, хотя не факт что он идеален. А если не соблюдать "алгоритм" нумерования, то я и мне подобные на выходе будут получать результат ничем не лучше, чем просто неотсортированный На практике сталкивался с магазином, в котором в 1-й главной всего 1 подуровень, но там .. 1500 подкатегорий, во 2-й главной все подкатегории короткие, но до 5 уровней вложенности. Понимаю, что сама организация категорий таким образом - не самый правильный вариант, но так есть. Организовать sort_order по Вашему принципу, конечно, возможно, но не так уж и просто, и точно не так уж удобно. Не уверен, что сортировка в sql по неиндексированным полям даст какой-то выигрыш. Вполне вероятно, что рекурсия в php отработает быстрее, чем простая сортировка по sort_order (в таблице category нет индекса по sort_order). Хотя тут, конечно, скорее всего многое еще будет зависить от того, что из себя представляет дерево категорий. В случае магазина со странной структурой категорий (который я привел в пример), наверное все же рекурсия будет медленнее. Поэтому, все же предлагаю дать право на жизнь и рассмотреть вариант "структурной" (рекурсивной) сортировки.

Просмотрев весь код, а не только его часть, вынужден признать свою неправоту и принести извинения перед NickZet "$limits as $limit" несет в себе проблему так как портит ранее установленную (и нужную) переменную $limit. "$limits as $limits" проблем в себе не несет, т.к. далее переменная $limits не используется, но все равно как-то неправильно такие конструкции использовать.

Согласен. Действительно, нет смысла чего-то воротить.

Честно говоря, мысли вплотную к этому подкрались :). Все же любые вопросы совместимости на мой взгляд являются плюсом (ну смотря какой ценой, конечно). Но сомнения в их правильности есть, поэтому и интересно мнение сообщества. Тут уж возразить нечего Таки есть что возразить

Ну это вопрос к минусовавшим Если внимательно прочитать пост, то он предлагает решить "проблему" (я так и не понял в чем там проблема) посредством изменения "$limits as $limit" на "$limits as $limits". Если бы наоборот, то хоть что-то здравое в этом было бы (хотя и не решало бы ничего, массив все равно переберется), а так ...

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

Структурно отсортированные категории позволяют не париться алгоритмом присвоения sort_order.Ну это не так важно. 2 решения лучше, чем ни одного :) Как генералы решат, так и будет.

Кстати, о совместимости. Есть легкая несовместимость между 1.5.4.1 и 1.5.5.1 в плане переменных.Например, в header то что в 1.5.4.1 "filter_name", то в 1.5.5.1 - "search". В результате - несовместимость шаблонов. Есть мысль, что бы отловить подобные моменты и в контроллерах продублировать выдачу и под 1.5.4.1 и под 1.5.5.1 ? С одной стороны не хорошо, что лишние переменные, с другой - классно, что можно безболезненно ставить шаблоны под 1.5.4.1 (ну и более ранние, на сколько версий - не знаю). Какие есть мнения на счет этого?

Очевидно, мы просто разные задачи перед собой ставили. Я выполнял такую задачу: вначале родительская категория с наименьшим значением sort_order, ниже дочерняя категория с наименьшим значением sort_order, ниже "субдочерняя" и т.д., независимо от уровня вложенности. Для этого нужна рекурсия. Если такой рекурсивный запрос и можно сделать, то у меня как минимум для этого познаний в SQL не хватает. Но я и не парился, т.к. даже если есть возможность выполнить эту рекурсию средствами SQL, то на 99% уверен, что php с этим справится на порядок быстрее. Предложенное Вами решение решает другую задачу - выдает категории отсортированные по sort_order, не структурируя их по уровням вложенности.

Как можно что-то "вылечить" изменив переменную итератора? Причем изменив так, что после выполнения цикла исходный массив будет испорчен.

Вы это осознанно пишите ...? Это же полный бред!

А вообще не хорошо получается с категориями в админке. Сторонние шаблоны не понимают - показывают только верхний уровень (проверено на Metro Admin UI). Нужно, наверное отдавать в .tpl оба врианта: стандартный (с пагинацией) и отдельной переменной - форматированное под нужный нам вариант. За выходные сделаю. Точно нужно менять - уход от совместимости - это плохо.