RGB

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

о, а почему я могу? :-)

почему-то никто не поддержал идею подобного https://opencartforum.com/topic/27246-%D1%87%D0%B0%D1%82-%D0%BD%D0%B0-%D1%84%D0%BE%D1%80%D1%83%D0%BC%D0%B5/ а ведь когда чатик встроен в форум, это на несколько лишних действий меньше, чем если для чатика надо заходить в джаббер

Напишите в теме о том, что за косяк https://opencartforum.com/topic/31428-%D0%BF%D0%BB%D0%B0%D0%BD%D1%8B-%D0%BD%D0%B0-%D1%80%D0%B5%D0%BB%D0%B8%D0%B7-15513-%D0%B8%D0%BB%D0%B8-1561/

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

Качайте мастер-версию с гитхаба, она ведь и будет релизом, если сейчас ничего нового из ошибок не появится. Заодно может сами обнаружите что-то Я как-то пропустил этот момент, а зачем ее полностью убрали? Можно ведь было просто display: none убрать, а не весь заголовок целиком

markimax не указал, что это доставка суши, а не традиционный магазин, а туда, как мне кажется, люди редко заходят с целью просто посмотреть цены или сравнить характеристики, как в магазины электроники например :) Поэтому, если у них вне магазина все на высоком уровне, доставка быстрая, конкуренция слабая, продукция классная + работает сарафанное радио, то почему бы и не получить 30%?

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

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

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

Вот спасибо, а я там посмотрел по структуре, вроде все похоже на старые версии, и решил, что в мастере пилят 1.5.6.2.

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

Спасибо что заметили, посыпаю голову пеплом :oops: Зато какой гремучий коктейль будет с бутстрепом и метро-плиточкой в ваших модулях :-)

Соглашусь с ravilr из-за пустого поля имейл проблемы гарантированно вылезут в очень многих местах, даже элементарно отредактировать информацию о покупателе не получится, поэтому либо нужно везде менять логику и ставить проверку на непустое поле (а тогда уже нужно и на другие поля смотреть, поскольку в симпл часто не заполняется обязательное поле страна, адрес, всякие там id компании и т.п.), либо все таки ориентироваться на базовую логику движка, где покупатели без имейлов не допускаются. Проблемы пользователей модуля Simple должен решать автор модуля, как мне кажется. Несмотря на его распространенность, было бы неправильно подгонять движок под устранение тех косяков, которые могут всплыть из-за сторонних модулей. Едем дальше: https://opencartforum.com/topic/27002-процесс-работ-над-релизом-ocstore-15512/?do=findComment&comment=219067 все отсюда проверил, кроме мультиязычного сеопро, на текущем мастере вроде все работает https://opencartforum.com/topic/27002-процесс-работ-над-релизом-ocstore-15512/?do=findComment&comment=222743 с привязками к категориям у меня тоже все нормально работало, либо проблему исправили, либо автор поста что-то не так сделал Проблема, обнаруженная Tom'ом, с шириной блока цены, которую видимо вставили в оригинальной версии исходя из того, что в инет-магазинах мало что продается с многозначными ценниками, отправил первый в своей жизни пулл-реквест, чтобы убрать такую вопиющую несправедливость :-) Там же запрет на вывод товара в сопутствующих, если товар добавлен сам в себя, по-моему вещь нужная, но не критичная, решение раньше предложил costas. Остались проблемы: https://opencartforum.com/topic/27002-процесс-работ-над-релизом-ocstore-15512/?do=findComment&comment=235209 1 - глюк с выбором родительской категории есть, категория действительно слетает, нужно как-то прилепить проверку, чтобы в списке категорий, доступных для выбора в качестве родительской, не было ид той категории, которую мы сейчас редактируем. 2 - рамка после нажатия на картинку для просмотра превью, я у себя решал дописыванием в стили следующего куска кода, но хз надо ли такие мелочи в пулл-реквесты вносить, поэтому если кому нужно - вот: a:active, a:focus, img { outline: 0; } Если ничего не пропустил из этой темы, то новых проблем пока никто не обнаружил (или не описал).

Видимо Daniel усомнился в целесообразности 1-го варианта, раз решил спросить свое комьюнити и предложить 2-й. А где вы скачали движок с этой версией?

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

Конечно нет, он скорее покажет отличия или сходство нашего мнения и мнения оф. англоязычного сообщества

Daniel родил скрины возможной будущей админки: 1. 2. Мое мнение - оба варианта так себе, в основном из-за нерационального использования верхней части (где 70% пустоты), туда можно было бы спокойно перенести боковое меню, сделав его горизонтальным, и легко увеличить ширину страницы

Почему бред? Все там правильно работает, по крайней мере в пределах текущей логики, которая основана на выборке значений через И как между атрибутами, так и между группами атрибутов. Другое дело, что можно было предусмотреть варианты переключения логики работы фильтра, но вы слишком много хотите от бесплатного встроенного фильтра. И вам спасибо, я думал только dinox может принимать их. Насчет того, что осталось - я думаю нужно сначала с ними разобраться, а потом смотреть дальнейший todo, чтобы не накапливать пулл-реквесты. Так вот, там вроде критичного ничего нет. По номерам: №35 (отправка почты покупателям конкретной позиции) Проблема действительно есть, но я не понял, почему нельзя было просто скопировать реализацию из 1.5.4.1 или 1.5.5.1, где все работало (правда без проверки на не-пустой имейл). Получается, что предложенное изменение строки 757 в admin/model/sale/order.php из этого пулл-реквеста $query = $this->db->query("SELECT DISTINCT email FROM `" . DB_PREFIX . "order` o LEFT JOIN " . DB_PREFIX . "order_product op ON (o.order_id = op.order_id) WHERE (" . implode(" OR ", $implode) . ") AND o.order_status_id <> '0'"); на вот это $query = $this->db->query("SELECT DISTINCT email FROM `" . DB_PREFIX . "order` o LEFT JOIN " . DB_PREFIX . "order_product op ON (o.order_id = op.order_id) WHERE (" . implode(" OR ", $implode) . ") AND o.order_status_id <> '0' LIMIT " . $start . "," . $end); с виду работает, но при этом не появляется нотис про успешную отправку письма (у меня не появился). В 1.5.4.1 эта строка выглядит так и прекрасно работает в таком виде: $query = $this->db->query("SELECT DISTINCT email FROM " . DB_PREFIX . "order o LEFT JOIN " . DB_PREFIX . "order_product op ON (o.order_id = op.order_id) WHERE (" . implode(" OR ", $implode) . ") AND o.order_status_id <> '0'"); Та же ситуация со второй измененной строкой. Исходно, в мастере, она такая: $query = $this->db->query("SELECT DISTINCT email FROM `" . DB_PREFIX . "order` o LEFT JOIN " . DB_PREFIX . "order_product op ON (o.order_id = op.order_id) WHERE (" . implode(" OR ", $implode) . ") AND o.order_status_id <> '0' LIMIT " . $start . "," . $end); Ее предлагается изменить вот так $query = $this->db->query("SELECT DISTINCT email FROM `" . DB_PREFIX . "order` o LEFT JOIN " . DB_PREFIX . "order_product op ON (o.order_id = op.order_id) WHERE (" . implode(" OR ", $implode) . ") AND o.order_status_id <> '0'"); В то время, как в 1.5.4.1 она выглядит следующим образом (и опять же, успешно работает): $query = $this->db->query("SELECT COUNT(DISTINCT email) AS total FROM " . DB_PREFIX . "order o LEFT JOIN " . DB_PREFIX . "order_product op ON (o.order_id = op.order_id) WHERE (" . implode(" OR ", $implode) . ") AND o.order_status_id <> '0'"); И третье изменения по этому реквесту строки return $query->row['total']; на это return $query->rows; в 1.5.4.1 вообще отсутствует, там изначально возвращается $query->row['total'] и с ним все работает. №33 (обрезание лишних пробелов в текстовых полях редактирования товара в админке) Вообще не критично, но не знаю, нужно ли это - наверное хуже не будет (контент-менеджеры точно спасибо скажут), а с другой стороны это еще один шаг в сторону от оригинальной версии. Хотя ocstore и так раскурочен серьезно, и такие мелочи не особо его усложнят, так что я скорее за, чем против, этого предложения. №30 (рекурсивная сортировка категорий) Не понятно, что там должно улучшится, то ли лыжи не едут, то ли реквест не полностью указан. №25 (сортировка файлов по дате изменения и увеличение макс. размера загружаемого файла) Согласен с toporchillo, сортировка это дело вкуса, кому то удобнее стандартная, а увеличение лимита аж до 3 гб это перебор, может быть есть смысл поднять с 300 мб до 500 мб, но те, кто такие файлы грузит в магазин, обычно могут позволить себе нанять специалиста, который поднимет лимиты до нужного уровня. №23 и №22 (скрытие описания категории и производителя на страницах, отличных от 1-й) На мой взгляд, тут есть и свои плюсы, и свои минусы. Плюсы конечно для поисковиков - меньше дублей контента, лучше отношений к сайту в целом, но это не критично и влияние таких дублей на позиции в выдаче очень слабое, поисковики уже давно научились понимать, что у инет-магазинов уникальность контента не может быть такой же, как например у новостных или информационных ресурсов. А вот минусы у этого предложения посерьезнее, я например у себя делал в описании некоторых категорий акции и спец предложения с анонсами, кроме того там может быть важная информация для покупателей, и если этот покупатель попадет на 2-ю страницу категории из поиска, то он эту информацию уже не увидит (поскольку эта инфа будет видна лишь при переходе на 1-ю страницу), так что мое мнение - эти изменения могут принести больше вреда, чем пользы. Конструктивные предложения приветствуются, кто хочет поспорить - подключайтесь, так мы быстрее получим стабильный релиз. Напоминаю, что открытые пулл-реквесты находятся здесь, мастер-версию можно скачать здесь, а ссылка на актуальный репозиторий - вот: https://github.com/myopencart/ocStore

Скачал себе мастер-версию и решил проверить что там и как, параллельно проверяя что из todo уже исправлено, получилось осилить пока что лишь первую половину темы до 10-й стр, вот что вижу: 0) Вроде бы все из основного списка на первой странице реализовано и работает, что радует. 1) Файл-менеджер разъезжается из-за неправильной ширины блока Для исправления надо везде, где он вызывается (например \admin\view\template\design\banner_form.tpl, строка 122) изменить width: 700 на width: 800 На эту тему есть пуллреквест, отправленный почти 2 месяца назад https://github.com/myopencart/ocStore/pull/34 и я честно говоря немного удивлен, почему в списке так много висяков и почему их никто не рассматривает? Если dinox не справляется с этим, то может быть как-то дать доступ к добавлению фиксов в мастер-версию для других членов ocTeam? Тот же Alexey например, который отправил больше всего решений - почти все они уже были бы в мастере еще в прошлом году. Я думал релиза нет потому что некому им заниматься, а тут оказывается уже готовые решения висят, их только принять нужно ведь, и все. 2) Немного кривая локализация возвратов, во втором случае похоже не хватает длины поля в бд Исправить - расковырять установочный скрипт opencart.sql, который в папке install, поиск по тексту - и замена на то, что кому больше кажется подходящим. 3) Все так же не работает восстановление пароля в некоторых почтовых клиентах, проблема и решение описаны и проверены: https://opencartforum.com/topic/22440-problema-vosstanovlenie-parolia-pokupatelia 4) Tom писал "Если присутствует товар не привязанный ни к одной категории(а такое вполне может понадобиться) , то фильтр товаров (Каталог-Товары) выкидывает ошибку" не смог повторить, в мастер версии все вроде работает как надо 5) Опять же, разжеванная проблема, решение которой висит в списке пуллреквестов, но его никто не принимает. На странице "Акции" не сортируются товары по количеству (всегда стоит 100), в то время как решение очень простое, нужно в файле \catalog\controller\product\special.php в строке 230 заменить это foreach($limits as $limit){ $this->data['limits'][] = array( 'text' => $limit, 'value' => $limit, 'href' => $this->url->link('product/special', $url . '&limit=' . $limit) ); } на это (с этими лимитс/лимитс неразбериха, но я уже так оставил, чтобы было по аналогии с другими контроллерами, хотя наверное правильнее заменить на что-то более понятное, но работает и так): foreach($limits as $limits){ $this->data['limits'][] = array( 'text' => $limits, 'value' => $limits, 'href' => $this->url->link('product/special', $url . '&limit=' . $limits) ); } 6) vico7 писал "При отключении в админке в "Локализация" не нужного языка, все равно остается вкладка с отключенным языком на страницах админки и приходиться заполнять поле "Название товара" на всех языках. Иначе - ошибка" не смог повторить, в мастер версии все работает как надо Думал и дальше смотреть конкретно по перечисленным багам, но если уже висит столько необработанных пуллреквестов, то получится двойная работа, ошибки уже исправлены, но не рассмотрены, а мы тут непонятно что тестировать будем. Короче ситуация странная.

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

Что лишь подтверждает необходимость доработки любого движка в каждой конкретной ситуации. Не обязательно переходить на впс и заморачиваться с кешированием, когда самое слабое место - запросы, и таким простым способом можно порезать все, выкинув ненужное (и конечно, пожертвовав возможной совместимостью с новыми версиями). Я тут подумал, если бы предусмотреть изменение таких запросов всем скопом через админку, это круто облегчило бы жизнь пользователю (но увы, я не представляю, как так на лету изменять модель). То есть может в виде модуля, чтобы были элементарные чекбоксы с тем, ЧТО стоит учитывать в запросах. Если магазин 100% будет одноязычным и одновалютным, то чтобы юзер просто снял галочку с чекбоксов мультиязычности и мультивалютности, и все запросы сразу перестали бы ее учитывать.

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

Про Токелау, очевидно же :)

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