100napb

Написал в ЛС. К теме топика это уже не относится.

этим запросом Вы посчитаете суммарное количество всех товаров, которые заказывал клиент. То есть если в одном заказе клиент указал 2шт товара А, а в другом - 3шт товара Б, а в третьем заказе 1шт товара С, то запрос вернет Вам в результате 6шт неизвестного товара - нельзя точно сказать какого - А, Б или С. Плюсом, в запросе нет учета статуса заказов (даже брошенные корзинки клиента посчитаются). Посему запрос некорректный. Добавьте к тому запросу, что я приводил выше в качестве примера условие customer_id='".$cid."' и почувствуйте разницу. Дальше не вчитывался, т.к. ошибка есть уже на самом старте + лично у меня это займет значимое время, которое есть интерес тратить только на платной основе. Раздел услуг на форуме Вам в помощь, как вариант.

Вы лишаете себя увлекательного квеста смотрим вьюшку формы заказа в админке - /admin/view/template/sale/order_info.tpl видим, что переменная, которая содержит дату - $date_added идем в контроллер /admin/controller/sale/order.php и находим как формируется значение нашей переменной:$data['date_added'] = date($this->language->get('date_format_short'), strtotime($order_info['date_added'])); Ага. Все просто. В языковых файлах есть настройка. Идем в /admin/language/ru-ru/ru-ru.php, ищем $_['date_format_short'] = 'd.m.Y'; меняем на $_['date_format_short'] = 'd.m.Y h:i'; profit !!!

Без проблем могу помочь написать запрос, который бы отражал все необходимую логику\информацию. Однако учтите, что связка указанных таблиц возможна только для зарегистрированных клиентов, т.к. в таблице oc_order поле customer_id заполняется только для зарегистрированных и авторизовавшихся перед оформлением заказа клиентов. Без однозначной идентификации клиента вся Ваша идея лишена смысла, т.к. на месте клиента который хочет обойти ограничение, можно либо зарегистрироваться на другую эл.почту или оформить заказ без регистрации. Как черновик, можете использовать вот такой запрос SELECT oo.customer_id, CONCAT(oo.firstname, oo.lastname), oop.model, sum(oop.quantity) FROM oc_order oo, oc_customer oc, oc_order_product oop WHERE oo.customer_id = oc.customer_id AND oop.order_id = oo.order_id GROUP BY oop.product_id, oc.customer_id HAVING COUNT(oop.product_id)> 1; на выходе будет что-то вроде такого: номер клиента --- ФИО --- название продукта --- количество единиц заказанных клиентом

Как вариант, стоит для начала убедиться, что комментарий успешно записывается в базу. Для этого вот Вам запрос для проверки, который выведет табличку с номером заказа и комментария к нему SELECT oo.order_id, oo.comment FROM oc_order oo ORDER BY oo.order_id DESC; Если комментариев в базе нет - стоит смотреть в сторону процесса сохранения\оформления заказа; Если комментарии есть - значит они просто не выводятся в форме заказа в админке. Уверен, в этом случае Вам поможет поиск по форуму

Список всех подписчиков можно получить выборкой из базы данных вот таким запросом: SELECT * FROM oc_customer oc WHERE oc.newsletter = 1; Если количество будет 0, то можно всем клиентам принудительно "включить" подписку слелующим запросом: UPDATE oc_customer oc SET oc.newsletter = 1 WHERE oc.newsletter !=1; а что там у Вас с формой подписки - разбирайтесь. Для проверки самостоятельно подпишитесь на новости и проверьте приведенным выше запросом - если все ок, то Ваш емейл должен быть в списке результатов.

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

Кажется, Вы сами ответили на свой вопрос У Вас нет подписчиков на новости. Откройте карточку любого клиента в админке и посмотрите, стоит ли галочка " Подписка на рассылку "

если Ваш файлик /www/system/library/cart/currency.php стандартный и не содержит правок, то на 33 строке у него вот такое: $amount = $value ? (float)$number * $value : (float)$number; в новых версиях пхп "ужесточил" правила приведения типов переменных и сообщает Вам о том, что значение одной из переменных определяется как нечисловое. В то время, как идет операция умножения, которая подразумевает, что работать будем с числовыми значениями. Что делать? Сделать принудительное преобразование значения переменной в число. Например так: $amount = $value ? (float)$number * (float)$value : (float)$number или вот так: $amount = $value ? (float)$number * (int)$value : (float)$number Пробуйте. Должно помочь.

Если Вам прям интересно понять разницу, то банально откройте sql-файлик бекапа и загляните в содержимое: какие сущности каким бекапом делаются. Вам совершенно верный ответ дал @Tom, а именно: бекап средствами OC делает бекап данных из существующих таблиц. Там и команды используются типа trucate table с последующим insert'ом данных. Ко всему прочему, структура файла и способ организации строк в бекапе средствами OC явно неоптимальный, из-за чего такая разница в объема файла. Я для себя ради интереса сделал в одно и то же время бекапы с сайта и открыл файлики бекапов посмотреть: там разница в количестве строк в несколько раз )) Другое дело, бекап средствами mysql\хостера: там снимается резервная копия ВСЕЙ базы, включая таблицы, их структуру, вьюхи, триггеры, индексы и прочая. Такие бекапы можно смело переносить на другие сервера\хостинги, в отличие от бекапа из ОС, который, судя по всему, без напильника подойдет только к этому же магазину, с которого был снят. По личному опыту скажу, что уже как с десяток лет пользуюсь командами типа: для дампа а для восстановления из бекапа: и ни разу не было проблем.

Не 6, а 5 в файле /admin/controller/catalog/category.php ищите вот эту функцию и измените всего 1 цифру, которая идет напротив `limit`. public function autocomplete() { $json = array(); if (isset($this->request->get['filter_name'])) { $this->load->model('catalog/category'); $filter_data = array( 'filter_name' => $this->request->get['filter_name'], 'sort' => 'name', 'order' => 'ASC', 'start' => 0, 'limit' => 5 ); а вообще... не помню, но по-моему (не уверен на 100%) при использовании SeoPRO Ваша задача решается из коробки, потому что вкладка "связи" имеет вот такой вид, с выводом всех категорий. Если у Вас русская сборка (ocStore), то в настройках магазина попробуйте включить тип ЧПУ SeoPRO

del.

Уточните хотя бы версию опенкарта о чем именно идет речь? Наверное, имелось ввиду: маркетинг -> почтовая рассылка -> в выпадающем списке выбрано "подписчикам" ? (/admin/index.php?route=marketing/contact) В любом случае, прежде всего Вам нужно проверить была ли фактическая попытка отправить письма? Запись об этом должна быть в логах сервера. Например, вот здесь: /var/log/maillog-YYYYMMDD. Запись от отправке \ попытке отправки ЛЮБОГО письма должна быть отражена в логах. Там же смотреть ошибки, если они есть и уже с ошибками писать сюда. Если никаких записей об отправке нет, значит фактически ничего и не отправлялось и, очевидно, надо копать в сторону проверки условий выборки получателей в контроллере\модели почтовой рассылки - вполне вероятно, что после нажатия кнопки отправить, система не находит ни одного получателя и ничего не отправляет. убедиться в отсутствии ошибок после отправки рассылки в логах опенкарта (система-инструменты-журнал ошибок) и логах веб-сервера. Помните, что половина ответа уже кроется в правильно заданном вопросе

Напишу ниже без иронии, т.к., очевидно, не все умеют в юмор и не видят толстых намеков )) Ваш запрос отрабатывает верно и показывает тот результат, который Вы запросили. Беда в том, что Ваш селект производит выборку из ДВУХ таблиц (product и product_description), но Вы не указали в условии запроса логику выборки. Вот и получается на выходе, что для каждой строки первой таблицы запрос отображает все записи из второй таблицы Об это Вам выше и толкуют, говоря про декартово произведение. вместо непонятного where 1 укажите явную логику выборки, например: where oc_product.product_id = oc_product_description.product_id по-русски говоря, объясните запросу, что хотите видеть в результате две таблицы объединенные по значению поля product_id, например. Чуть подучите матчасть по простейшим sql-запросам прежде чем просить помощи. Займет немного времени, и у участников любого ресурса будет больше желания помогать, видя тот факт, что Вы хотя бы старались

Я лично с Вами согласен и вот почему: Постоянно Вы этим функционалом пользоваться не будете. Потому коммерческий смысл вкладывать деньги в разработку того, что не окупится, весьма сомнителен Помимо phpAdmin есть масса специализированного и даже бесплатного софта для работы с БД, на фоне которого phpAdmin уныл, кастрирован и неудобен. Взять хотя бы Toad или какой-нибудь DbForge. Есть предложение решить Вашу задачу нехитрыми sql-запросами, которые бы работали с заранее подготовленными в дружелюбном экселе данными. Я бы для себя сделал так: создал бы в БД табличку, в которую бы импортировал подготовленные в экселе данные. А далее прогонял бы в базе пару sql-запросов, которые бы делали\снимали привязки товаров из нашей таблички к категориям. Дешево и сердито