Yesvik

Даёш руку на отсечение что при работе с $this->request->post['Blog'] не понадобятся данные из $this->request->post['User']? Только не надо рассказывать что криво построена модель и т.д., ситуации разные бывают. Я ничего против Кристала не имею, я за то что-бы каждый инструмент использовался по назначению и не был избыточным. Микроскопом можно забить гвоздь, но не нужно... для этого есть молоток. И если у тебя в багажнике лежит молоток - совсем не обязательно ложить туда второй только потому что у него ручка красивее. Если есть четкое обоснование того что надо два молотка - тогда без проблем... А я пока не услышал ничего кроме "код красивее". Если нет четкого ответа на вопрос - ничего страшного и не надо искать оправданий. Ну нравится тебе Кристал и ладно... Да мне не нравится то как реализована работа с БД и я думал что ты действительно нашел нечто что ускользнуло от меня при знакомстве с Кристалом, потому и спросил. По большому счету - старый, добрый, DbSimple Димы Котерова гораздо интереснее чем Crystal, как минимум за счет наличия плейсхолдеров, макроподстановок и более интересных вариантов выборки данных.

В файле admin/model/catalog/product.php ищем строку $tags = explode(',', $value);эта строка встречается 2 раза и после каждой найденной строки добавляем строку $tags = array_filter(array_map('trim', $tags), 'strlen'); В файле catalog/model/catalog/product.php ищем строку $keywords = explode(" ", $tag);эта строка встречается 2 раза и после каждой найденной строки добавляем строку $keywords = array_filter(array_map('trim', $keywords), 'strlen'); Теперь надо вычистить из таблицы oc_product_tags записи с пустыми тегами. Сделать это можно разными способами, например вот таким SQL-запросом: DELETE FROM oc_product_tags WHERE tag = '';Только не забудь исправить префикс таблицы oc_ на свой.После этого строка $number = preg_replace('/\D+/', '', $keyword);или $number = preg_replace('/[^0-9]+/', '', $keyword);будет нормально отрабатывать и trim() не понадобится.В OpenCart 1.5.х ситуация частично лучше, но всё равно полностью не исключена возможность записи пустых тегов и требует аналогичной обработки для исключения проблем.

Да, долго бы ещё гадали... Проблема в кривой модели добавления и редактирования товара и рахитском алгоритме поиска. Кроме поиска в названиях, описании и модели - постоянно идёт поиск по тэгам и реализован он через ... Всё начинается с модели товара. Когда добавляется или редактируется товар - вот так обрабатываются теги: foreach ($data['product_tags'] as $language_id => $value) { $tags = explode(',', $value); foreach ($tags as $tag) { $this->db->query("INSERT INTO " . DB_PREFIX . "product_tags (product_id, language_id, tag) VALUES ('" . (int)$product_id . "', '" . (int)$language_id . "', '" . $this->db->escape(trim($tag)) . "')"); } } Никакого контроля на наличие тегов и в результате, для товаров без тегов, получаем записи с пустыми значениями.Дальше за дело принимается поиск по тегам... $keywords = explode(" ", $tag); foreach ($keywords as $keyword) { $sql .= " OR pt.tag = '" . $this->db->escape($keyword) . "'"; } Вот из-за этой хрени - пробел в начале, пробел в конце или двойной пробел в середине приведут к поиску товаров с пустыми тегами, а их у нас предостаточно из-за подарка в модели...Так что регулярка тут не при чем и трим работает нормально. Чуть позже напишу что делать с этим безобразием.

Даже без "подарков" от верстальщика, частенько из одной формы надо раскинуть данные по разным таблицам.

По хорошему в Кристале надо перед выполнением запроса вот такое добавлять $allowed = array(store_id, firstname, lastname, email, telephone, fax, password, newsletter, customer_group_id, status, date_added); $data = array_intersect_key($data, array_flip($allowed));Это немного добавит наглядности запросу, и защитит от "подарков" со стороны верстальщика :)

Лично мне намного приятнее видеть вот такой запрос $this->db->query("INSERT INTO " . DB_PREFIX . "customer SET store_id = '" . (int)$this->config->get('config_store_id') . "', firstname = '" . $this->db->escape($data['firstname']) . "', lastname = '" . $this->db->escape($data['lastname']) . "', email = '" . $this->db->escape($data['email']) . "', telephone = '" . $this->db->escape($data['telephone']) . "', fax = '" . $this->db->escape($data['fax']) . "', password = '" . $this->db->escape(md5($data['password'])) . "', newsletter = '" . (isset($data['newsletter']) ? (int)$data['newsletter'] : 0) . "', customer_group_id = '" . (int)$this->config->get('config_customer_group_id') . "', status = '1', date_added = NOW()");Посмотрел и сразу всё понятно, всё под контролем, не надо лазить по коду и выяснять что там в этой $data, не попало ли туда что-то лишнее.Смотреть надо и контроллер и вьювер, мало ли чего во вьювере дизайнер начудит. А пока полазил - глядиш и скорость разработки уже совсем не скорость, а тормоз...

А если вот так сравнить? $data['store_id'] = (int)$this->config->get('config_store_id'); $data['customer_group_id'] = $this->config->get('config_customer_group_id'); $data['status'] = 1; $data['date_added'] = NOW(); $data['password'] = md5($data['password']); $data['newsletter'] = (isset($data['newsletter']) ? (int)$data['newsletter'] : 0); $this->crystal->insert(DB_PREFIX."customer", $data)->execute(); и $data['store_id'] = (int)$this->config->get('config_store_id'); $data['customer_group_id'] = $this->config->get('config_customer_group_id'); $data['status'] = 1; $data['date_added'] = NOW(); $data['password'] = md5($data['password']); $data['newsletter'] = (isset($data['newsletter']) ? (int)$data['newsletter'] : 0); $data = array_map(array($this->db, 'escape'), $data); $this->db->query("INSERT INTO ".DB_PREFIX."customer (".implode(',', array_keys($data)).") VALUES (".implode(',', $data).")"); как бы и разницы уже почти нет...

Все таки давай по честному... Куда делось $data['newsletter'] = (isset($data['newsletter']) ? (int)$data['newsletter'] : 0);и вот это $data['date_added'] = NOW();скорее всего не пройдёт, потому что думаю получиш date_added = 'NOW()'и тут надо будет raw'ом изголяться, с лёту даже не соображу как именно... и уже не так красиво получается.Да и пример ты взял который выгоден тебе, с готовым массивом данных. Если готовить массив с нуля - то разница будет только в том что надо эскейпить и я об этом говорил.

Можно точнее указать радиус изгиба загрузки шаблона и версию магазина? :)

По большому счету Crystal ничего не даёт, только синтаксис другой... $information = $this->crystal->get(DB_PREFIX.'information_description') ->where(array('information_id' => 1, 'language_id' => 1)) ->fetch_row(); и "SELECT * FROM ".DB_PREFIX."information_description WHERE information_id = 1 AND language_id = 1"особой разницы в скорости разработки не вижу (Crystal только экранирует сам), а по скорости работы - Crystal проиграет, потому что ему надо собирать SQL-запрос.Валидация которая есть в Crystal не принципиальна, multiple - тоже не нужен, а когда начнёш собирать трёхэтажные джойны - запаришся обдумывать как он соберёт запрос и думаю без вставок raw'ом не обойдёшся... Поделись соображениями в каком месте жизнь облегчается...

https://opencartforum.com/files/file/87-%D1%8D%D0%BA%D1%81%D0%BF%D0%BE%D1%80%D1%82-%D0%BA%D0%B0%D1%82%D0%B0%D0%BB%D0%BE%D0%B3%D0%B0-%D0%B4%D0%BB%D1%8F-%D1%8F%D0%BD%D0%B4%D0%B5%D0%BA%D1%81%D0%BC%D0%B0%D1%80%D0%BA%D0%B5%D1%82/ Японии точно не будет и возможно остальные проблемы решатся.

А попробуй посмотреть что такое $keyword Это как раз и есть только что написанный пользователем текст...

Так символ в символ, как раз и будет требовать наличия базы с заразами. А если зараза умеет модифицироваться? запаришся... Поэтому я и предложил по какому фрагменту можно отлавливать независимо от того как модифицировано тело заразы. Такая <html><body><script> последовательность в реале не встречается, и можно смело резать...

Этот пункт написан неоднозначно и можно трактовать по разному. Я считаю что автор имел ввиду следующее:Если в тайтле 200 символов - то наиболее значимые ключевики должны быть в первых 70-80 символах. Положение ключевиков в пределах этих 70-80 символов - роли не играет. В комментах к другой статье http://devaka.ru/articles/title-length-experiment Devaka даёт прямой ответ на этот вопрос.

Скачать / Купить дополнение ocStore v1.0.0 - Устранение дублей страниц товаров и категорий Формирует постоянные URL категорий и товаров. В разделе "Ссылки" товара можно основную категорию товара, относительно которой формируется URL. URL товаров могут строится с учетом иерархии категорий или без: /category/subcategory/product или /product При выборе построения URL /product хлебные корошки и меню формируются с учетом полного пути к товару (с категориями/подкатегориями) Для этого в админке, в разделе Настройки есть пункт "SEO-url товаров с категориями". Там же можно указать окончание для ЧПУ. Например, если указать .html то ссылки товара будут вида: /category/subcategory/product.html Если для построения ЧПУ не хватает какого-то псевдонима - URL строится GET параметрами, при этом параметр path, который отвечает за иерархию категорий, всё равно контролируется и формируется с учетом заданной иерархии категорий. Для снижения нагрузки используется кеширование в два файла - отдельно для товаров и категорий Обновил архив 19.07.2011 Добавил Yesvik Добавлено 18.07.2011 Категория Прочее  

В описанных выше границах положение слова в тайтле на вес не влияет.http://devaka.ru/articles/title-tag-optimization http://bakalov.info/rasstanovka-klyuchej-v-title-po-chastotnosti.html

#<html><body><script>.+? </script></body></html>#s только без пробела после вопроса

В тайтл помещается гораздо больше 60 символов, но нас интересует то что попадает в результаты поиска и учитывается поисковиками. Экспериментальным путем выяснено: Яндекс - длина заголовка в результатах поиска может содержать до 80 символов, но учитывается не более 15 слов. Google - длина заголовка в результатах поиска может содержать до 70 символов, но учитывается не более 12 слов. (Если точнее - то учитывается больше но с меньшим весом)

<?php echo $product_info['sku']; ?>

Я не верно выразился, читай "в результаты поисковой выдачи".

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

Всё верно, исключает.Эта регулярка [^0-9]+ означает всё кроме цифр, а функция preg_replace('/[^0-9]+/u', '', $keyword) по русски звучит примерно так: найти в $keyword всё кроме цифр и удалить (заменить на '' ). Модификатор u предписывает рассматривать шаблон в кодировке UTF-8. Почему не работает - не знаю.

Посмотри вот тут https://opencartforum.com/topic/2877-%D1%80%D0%B5%D1%88%D0%B5%D0%BD%D0%BE-%D0%B2%D0%B5%D1%80%D0%BD%D1%83%D1%82%D1%8C-%D0%BF%D1%80%D0%B0%D0%B2%D0%B0-%D0%B3%D0%BB%D0%B0%D0%B4%D0%BC%D0%B8%D0%BD%D0%B8%D1%81%D1%82%D1%80%D0%B0%D1%82%D0%BE%D1%80%D0%B0/page__p__19385#entry19385

Если галочки у остальных пунктов не снимала - то проблема ни как не связана с новостями. Проблема на локалке или на хостинге?

О525 Вот эти символы - это 200% UTF-8 с BOM.