100napb

не удержался, обновил кодировки в таблице oc_order_history. Теперь отправляю красивые письма клиентам )) Вот так в истории заказов: А вот так у получателя:

решал для себя подобную задачку. может пригодится

решал для себя подобную задачку. может пригодится

решал для себя подобную задачку. может пригодится

решал для себя подобную задачку. может пригодится

решал для себя подобную задачку. может пригодится

решал для себя подобную задачку. может пригодится.

Здравствуйте, уважаемые. Пропустим ту часть, в которой обсуждался бы вопрос откуда у Вас могут появиться всякие няшные смайлики. Скажу лишь, что лепить их направо и налево со всяких гаджетов любит каждый, в том числе, оставляя отзывы у Вас на сайте. Так вот, задался вопросом, как сохранить и не исказить все эти дорогие эмоции. Потому что ОпернКарт с ними не дружит. Для себя нашел следующие решение: Прежде всего, текст со смайлами или без них хранится в БД. Для этого данные должны быть в хипстерской кодировке utf8mb4. И сама БД ее должна поддерживать. Не у всех стоят последние версии Mysql, где все это работает не просто из коробки, а по умолчанию. Что бы перевести таблицу на кодировку с эмодзи выполним ALTER TABLE table_name CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; где table_name заменяем на нужные таблицы. Можно и всю базу так заальтерить, но я чет очканул. Мне хватило таблиц oc_review и oc_comment (привет Markimax). Обновлять версию мускуля не обязательно. Если только он настолько старый, что о такой кодировке даже не знает. В настройках коннекта к БД опенкарта так же сменим кодировку: файл /system/library/db/mysqli.php, $this->connection->set_charset("utf8mb4"); Вроде бы все... ах да, возможно, нужно менять параметры кодировки в файлах mpdo.php и mysql.php. Я менял. Может быть придется еще рестартануть службы. Под спойлером результат. Может кому пригодиться. Ну и вопрос для сведущих: можно было как-то проще\грамотнее это сделать?

Отлично. Спасибо за ответы. Как доплатить?

красавчик )

Я понимаю в SQL, но не понимаю задачи. Что значит - перемешались? Единственное, что приходит на ум: у товаров есть такой параметр, как сортировка. Она отвечает за порядок вывода в категориях, например. Можно написать запрос, который бы выставлял случайное значение сортировке, что "перемешает" товары. Сколько их у Вас, товаров?

для будущих поколений отпишитесь пожалуйста по результатам - удалось\нет решить задачу )) ну и мне интересно, чего уж лукавить.

В общем ладно... надеюсь разберетесь если между товарами из баз test1 и test2 связь по полю product_id если между товарами из баз test1 и test2 связь по полю name рекомендую предварительно проверить результат работы скрипта на одном товаре, ради спокойствия. Для этого в запросе четко укажите product_id товара

Так. Великолепно. Это скриншот из базы, где есть и заполнено мини-дискрипшн. Если Вам нужно аккуратно ДОПОЛНИТЬ таблицу из другой базы, в которой все то же самое, но только поле мини-дискрипшн пустое, то покажите пожалуйста такой же скрин из другой базы, где было бы видно, товар "LED лампа Е27 А60 11W Евросвет". Так можно будет понять, по каким полям базы можно связать строки и дополнить данные

эм... я не вижу Ваших таблиц и данных - отталкиваюсь лишь от Вашей же информации. Сам по себе SQL-запрос верный. Возможные ошибки: Вы скопировали\вставили запрос не полностью (на скрине он обрезанный, т.к. нет второй строки из моего примера выше "SELECT mini_description FROM test2.poduct_description" ) разве в названиях Ваших таблиц нет префикса типа ос_ ? то есть, таблица на самом деле называется poduct_description, а не oc_poduct_description ? Хорошо, что столбец есть. А что касается второй части моего вопроса: Это так? если да, то а) запрос будет другой б) не советую выполнять тот, что указан выше, т.к. создадите уйму ненужных новых строк

Я думаю что потянет. Но производительности атома будет иногда не хватать. Сжатие\ресайз\оптимизация картинок, например, будет загружать его на 100%. И, возможно, надолго. Да разово, да после каждой очистки кеша. Но ситуаций, подобной этой, будет немало. Без хорошего модуля кеширования однозначно будет грустно \ вам буквально придется им обзавестись. Без всякой рекламы, только личный опыт: Jet Cache от Марка справится + можно гибко настроить\ с помощью него обойти узкие места. Тюнинг СУБД. MySQL или что там у Вас. Скорость выполнения запросов при таком количестве товаров может стать бутылочным горлышком. Скорее всего, достаточно будет оптимально подобрать конфиги самого сервера БД. В особо тяжелых случаях - профилировать и оптимизировать наиболее медленные запросы. Вполне могут выползти модули с неоптимально написанным кодом, "кривая" работа которого при таком количестве товаров будет более очевидной (избыточное использование памяти, медленное выполнение кода, опять же нерациональные SQL-запросы) Nginx. Используйте его как фронт перед апачем. Он быстрее\меньше жрет ресурсов. Первое что пришло в голову. Список, уверен, легко продолжат другие участники форума. Универсальных решений точно нет, т.к. оптимизация крупных проектов - задача комплексная. Для примера: у меня магазин прекрасно себя чувствует на дешевом VPS с 1 ядром, 512 озу да ссд с десятком-других гигов - спокойно выдерживает нагрузочное тестирование сотней-другой единовременных виртуальных юзеров и обеспечивает ttfb на уровне 150мс с любой страницы. Но у меня и нет 10к товаров, конечно. Да и "на холодную", с пустым кэшем, чего уж лукавить, показатели совсем не такие веселые - тут вся слабость железа и видна))

предположим, речь про стандартный модуль формирования карты сайта Google Sitemap. Если взглянуть в его контроллер (под спойлером), то список товаров получается стандартными методом model_catalog_product->getProducts(). Редактировать его - плохая идея, так как он овер дофига где используется и это 100% выйдет боком. что я предлагаю? Я предлагаю скопировать функцию getProducts из файла /catalog/model/catalog/product.php внутрь файла контролера Google Sitemap, модифицировать и локально. Что модифицировать? Условия выборки товаров из БД. Ищите эту строчку. То что выделил красным - убрать. $sql .= " LEFT JOIN " . DB_PREFIX . "product_description pd ON (p.product_id = pd.product_id) LEFT JOIN " . DB_PREFIX . "product_to_store p2s ON (p.product_id = p2s.product_id) WHERE pd.language_id = '" . (int)$this->config->get('config_language_id') . "' AND p.status = '1' AND p.date_available <= NOW() AND p2s.store_id = '" . (int)$this->config->get('config_store_id') . "'"; Должно все получится. Enjoy!

Грубо говоря, Ваш сайт не возвращает заголовков в ответе, что он "услышал" и принял во внимание в запросе от клиента\браузера готовность получать сжатые данные. Вот, на скриншоте и правда нет нужного заголовка ответа... у Вас ведь nginx трудится... убедитесь, что в его конфигах указан следующий параметр: gzip_vary on если нет - добавьте, перезагрузите сервис\службу nginx, проверьте. вот вполне исчерпывающая статья

есть необязательное, но очень желательное условие: обе базы должны быть на одном сервере. Так же, в структуре таблицы poduct_description из базы test2 должен существовать столбец mini_description. Есть он у Вас там? А так, все просто - используется синтаксис типа insert into db1.table1 (value1) select value1 from db2.table2 Так что итоговой запрос будет такой: INSERT INTO test2.poduct_description (mini_description) SELECT mini_description FROM test2.poduct_description Но что-то мне подсказывает, что результат Вас не устроит )) Потому что условия задачи некорректные. Выполнение запроса выше по Вашим условиям, просто насоздает кучу новых строк в таблице с одним единственным заполненным полем mini_description. Можно не одно поле селектить\инсертить - хоть все поля таблицы. Получится дубль целой таблицы или их объединение )) Cкорее всего, Вам нужно что бы существующие строки в базе test2 ДОПОЛНИЛИСЬ полем мини-дисткрипшн из соответствующих им строк в базе test1. Ага? Если так, то нужно знать, по каким полям искать соответствие между таблицами в разных базах (id-шники товаров не совпадают поди в таблицах; может по столбцу name искать соответствие - оно одинаковое?) Волшебно будет, если приложите образец данных с каждой таблицы. Хоть по паре строк, которые нужно объединить. Скришнот там или че... тогда получится предметно помочь, а не советы давать а-ля гадание на кофейной гуще.

del.

Понял. Пишите в ЛС какой-нибудь контакт для оперативной связи - обсудим. Как минимум несколько раз уже настраивал подобное для своих проектов. Еще разок смогу без проблем.

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

Здравствуйте, уважаемый автор! Я верно понимаю, что реализовать посредством данного модуля отзывы о магазине не получится - нужен другой Ваш модуль? А то создал Виджет: Формы, голосования, привязал к схеме, пытаюсь вывести куда-нибудь и не выходит.

@d0tb0t, чем закончился-то Ваш квест?

Блин, я думал вопрос уже решенный... вот рабочий селект на SQL, без регулярки. Просто, быстро и надежно. В запросе можно указать id-шники КОНКРЕТНЫХ категорий товаров, в которых нужно что-то заменить. Для примера, у меня это 62, 63. В переменную @find НУЖНО вписать ВАШУ строку, включая html тэги, начиная с которой всё последующее из описания товаров будет вырезаться. Id-шники категорий элеметнарно подсмотреть в админке опернкарта - просто навести мышкой на иконку карандашика редактирования категории и посмотреть на ссылку перехода - как на рисунке Если селект возвращает правильные результаты, переделывайте его в update и profit. Если не уверены на 100%, выполняя апдейт по базе, то делайте бекап таблицы!!! SET @find = '&lt;strong&gt;Характеристики:&lt;'; SELECT REPLACE(opd.description, SUBSTRING(opd.description, LOCATE(@find, opd.description)), '') FROM oc_product_description opd WHERE opd.product_id IN (SELECT product_id FROM oc_product_to_category WHERE category_id IN (62, 63)); специально убрал под спойлер пример апдейта