какие операции не связанные с обнулением этого нула с ним ещё проделаны? в сравни с оригиналом.
просто шас поставил, сразу вот что то картинок не видно товара и пр. так, что бы знать что там убрано... спасибо.
Я там писал про изменения. Из важного ничего не менялось, картинки порезаны. С тех пор приличное кол-во изменений внесли, в пору выкладывать собственный апдейт.
Косяки текущей версии okay CMS:
1.Выгрузка яндекс директ YML не работает на большой базе (недостаточно памяти). Решено.
2. Интеграция мультиязычной поддержки привела к серьезному замедлению системы на больших базах (2.5 сек для главной страницы - перебор) - решено
3. Включенный imagick вместо GD дает заметное невооруженным глазом снижение качества картинок - решено.
4. Добавлена функция автоматической генерации мета тегов не только для товаров, но и для разделов сайта.
5. Добавлен новый порядок сортировки товаров на сайте: random и сортировка по популярности (кол-во просмотров карточек товаров), теперь у нас по-умолчанию используется именно этот способ.
6. По нашей просьбе разрабы сделали нам еще вот что. обычная симпла в шаблоне для категории products.tpl давала переменную $brand, если из категории выбран еще какой-то бренд. В окее такую возможность порезали, мы попросили и нам вернули. Очень нужно для СЕО.
7. Увеличили кол-во отображаемых товаров в админке, теперь посмотреть можно 200, 300, 400 и 500 товаров.
8. Значительно расширен генератор sitemap.
9. Одно из самых важный изменений!!! Если кто знает, и Симпла, и ее незаконнорожденный ОКЕЙ имели такой жестокий недостаток. Если в админке в разделе Свойства товаров ты хочешь отключить фильтр какого-то параметра не во всех разделах, а только в определенных, это можно сделать, ткнув на нужный параметр и выбирая галочками категории. Всегда думали, что отключение приводит к исчезновению соответствующего фильтра на сайте, а включение возвращает все назад. Оказалось, что система ведет себя иначе. В случае отключения галочки какой-то категории в настройках свойства товара, система не только выключает его, но и удаляет значения этого свойства у всех товаров этой категории. Вы отключили, например, длину, а система взяла и убила все параметры длины у товаров в этой группе! Разрабы окея в ответ на вопрос об этом, сказали, что это не баг, а фича.
Мы отключили эту "фичу" у себя. Чтобы удалить какие-то свойства у товаров, надо удалить само свойство, а не просто снять галочку.
Люди, кто шарит в mysql.
В ходе багтрахинга на окее 1.2.2 выяснилась причина долгой загрузки главной страницы. Оказалось, что
get_new_products функция, которая работает через фукнцию get_products
выполняется медленно на нашей большой базе, а причина замедления вот этот запрос.
Код:
SELECT DISTINCT p.id, p.url, p.brand_id, p.position, p.created AS created, p.visible, p.featured, p.rating, p.votes, p.last_modify, l.name, l.meta_title, l.meta_keywords, l.meta_description, l.annotation, l.body, l.special
FROM s_products p
LEFT JOIN s_lang_products l ON l.product_id = p.id
AND l.lang_id =1
WHERE 1
AND (
SELECT count( * ) >0
FROM s_variants pv
WHERE pv.product_id = p.id
AND (
pv.stock IS NULL
OR pv.stock >0
)
LIMIT 1
) =1
AND p.visible =1
ORDER BY p.created DESC
LIMIT 0 , 4
Работа запроса на базе 60к товаров, выполняется примерно 2 секунды. Причем, если из запроса убрать LEFT JOIN s_lang_products, все нормально работает.
Код:
SELECT DISTINCT p.id, p.url, p.brand_id, p.position, p.created AS created, p.visible, p.featured, p.rating, p.votes, p.last_modify
FROM s_products p
WHERE 1
AND (
SELECT count( * ) >0
FROM s_variants pv
WHERE pv.product_id = p.id
AND (
pv.stock IS NULL
OR pv.stock >0
)
LIMIT 1
) =1
AND p.visible =1
ORDER BY p.created DESC
LIMIT 0 , 4
Такой запрос выполняется 0.0007 секунд!
Вот EXPLAIN от злополучного запроса.
Блин, возникла проблема с поиском. Дело в том, что поиск хочет искать в поле l.name, которой на момент вывода перечня товаров еще нет, если переставить поиск после этой таблицы, то он будет искать, но только в ограниченной limit выдаче.
Засада.
Так поиск работает, но выдает кучу страниц, где на каждой странице всего по 1 или 2 товара.
Код:
"SELECT
p.*,
$lang_sql->fields
FROM (SELECT DISTINCT
p.id,
p.url,
p.brand_id,
p.position,
p.created as created,
p.visible,
p.featured,
p.rating,
p.votes,
p.last_modify
FROM __products p
$category_id_filter
$variant_join
$currency_join
$yandex_filter
WHERE
1
$product_id_filter
$brand_id_filter
$features_filter
$is_featured_filter
$discounted_filter
$in_stock_filter
$visible_filter
$price_filter
$group_by
ORDER BY $order
$sql_limit) p
$lang_sql->join
WHERE 1
$keyword_filter
"
Еще вариант не искать в языковой таблице совсем, но тогда зачем он вообще нужен этот язык?
Придумал 3 вариант. Вернуть концепцию запроса, если осуществляется поиск по сайту.
Остановились на 3 варианте. Для поиска используется стандартная конструкция. Сначала join таблицы товаров с языками, потом поиск по базе и выдача с установленным лимитом. Поиск работает, конечно, дольше, но зато функциональность никак не пострадала, а скорость работы даже выросла.
На наших 56 тыс. товаров все это заметно невооруженным глазом. Главная страница, пагинация по разделам, все работает быстрее.
Вот что нужно поменять:
кусок кода в get_products,
начиная с
заканчивая,
меняем на
Код:
if(!empty($filter['keyword']) || !empty($filter['keyword'])) {
$query = "SELECT DISTINCT
p.id,
p.url,
p.brand_id,
p.position,
p.created as created,
p.visible,
p.featured,
p.rating,
p.votes,
p.last_modify,
$lang_sql->fields
FROM __products p
$lang_sql->join
$category_id_filter
$variant_join
$currency_join
$yandex_filter
WHERE
1
$product_id_filter
$brand_id_filter
$features_filter
$keyword_filter
$is_featured_filter
$discounted_filter
$in_stock_filter
$visible_filter
$price_filter
$group_by
ORDER BY $order
$sql_limit
";
} else {
$query = "SELECT
p.*,
$lang_sql->fields
FROM (SELECT DISTINCT
p.id,
p.url,
p.brand_id,
p.position,
p.created as created,
p.visible,
p.featured,
p.rating,
p.votes,
p.last_modify
FROM __products p
$category_id_filter
$variant_join
$currency_join
$yandex_filter
WHERE
1
$product_id_filter
$brand_id_filter
$features_filter
$is_featured_filter
$discounted_filter
$in_stock_filter
$visible_filter
$price_filter
$group_by
ORDER BY $order
$sql_limit) p
$lang_sql->join
WHERE 1
$keyword_filter
";
}
Вылез еще 1 интересный баг. Я так и не смог понять в чем дело.
После манипуляции с этим запрос везде все складно, кроме корзины. Сама корзина работает, но вот при добавлении туда товара в информере сверху изменений не происходит.
Вот до чего я доковырялся.
api/cart.php метод get_cart()
использует метод get_products(), который мы изменили. используется get_products вот как:
Код:
//объявляем переменную в виде массива.
$products = array();
//циклом для каждой строки stdObject, который у нас получается
//путем fetch_object в методе db->results(), который вызывается
//get_products, мы добавляем это в наш $products с элементами
//в виде id товара p->id
foreach($this->products->get_products(array('id'=>$products_ids, 'limit' => count($products_ids))) as $p) {
$products[$p->id]=$p;
//имеем на выходе $products со всеми товарами в корзине, какими именно написано в
//$products_ids, который берет это в $_SESSION['shopping_cart']
Если бы что-то не работало, то информер не показывал бы товаров в корзине вообще, а он показывает их при обновлении страницы, не показывает после клика на кнопку купить.
Сделал родной запрос $query не только для поиска, но и для случаев, когда указываются id (корзина).
Теперь информер работает.
Но в чем была причина такого поведения???
Очевидно, что данные о том, что товар добавлен отправляются, но ajax корзина не обновляет информер. Почему?
Кто нибудь может мне ответить?
Спасибо большое и респект за!
