ivan-lev: Ясно теперь.. Фантазировал, как Boost будет интернет-магазин ускорять, для уверенности на страничку заглянул в схемку - мало ли, вдруг изменилось чего...
Просто в моём понимании, это своего рода баг системы. Наличие сессии не значит, что пользователь залогинен. Информация о товарах в корзине хранится и для анонимных пользователей. Могут ещё многие вещи хранится в сессии. Поэтому я и удалил условия в ядре, которое проверяет наличие сессии. Это обсуждалось уже на drupal.org. Я так и не понял, что они там решили.
Simba_king: Скорей всего я просто не понял, сайт без CMS.
Если сайт без CMS, то только разработчик скрипта знает, где прописываются логин и пароль. Нужно найти откуда скрипт берёт данные, которые использует в mysql_connect().
forest25: «дополнительных модулей кэширования» - вот тут хотелось бы поподробнее. Какие из них реально помогают, а какие глючная поделка?
Всё зависит от вашего сайта. Я использую Block Cache Alter (https://drupal.org/project/blockcache_alter) и Entity cache (https://drupal.org/project/entitycache). Плюс настройка кэширования блоков в Views. Вам могут помочь и другие модули, но сказать какие именно не могу, так как это зависит от конфигурации и функционала сайта.
forest25: Да, точно Boost =) Ну вот та же корзина к примеру. Например сгенерилась страница каталога и закешировалась полностью. Пользователь закинул товар в корзину, но кол-во товаров отображается прежним т.к. страница снова отдалась из кеша. Я про такого плана возможные косяки.
Я для корзины использую Ajax Blocks (https://drupal.org/project/ajaxblocks). Он подгружает блок с корзиной через Ajax. Вся остальная страница остаётся закэшированной через Boost. Правда, мне пришлось ядро Drupal пропатчить, так как он не даёт создавать кэш страницы, если сессия содержит какие-то данные.
forest25: Делал не я. Сайт мне уже достался таким. У меня другое мнение насчет скорости его работы. Есть что сказать по существу? В плане действий по оптимизации.
Ставите Devel, смотрите запросы к базе данных для каждой страницы и выясняете что именно даёт нагрузку. После этого пытаетесь понять как оптимизировать нагрузку. Ряд запросов можно убрать путём установки дополнительных модулей кэширования. Некоторые запросы можно убрать какими-то простыми действиями (загрузка более новой версии перевода и т.д.).
---------- Добавлено 31.07.2013 в 20:39 ----------
forest25: Ребят, подскажите плиз варианты по оптимизации скорости Drupal Commerce? Настройка серверного ПО не в счет, интересуют именно варианты справильной настройкой кэширования, установкой доп. модулей и т.д.
Алсо, корзина сделана на views. Можно ли там включать кэширование или будут глюки у покупателей с товарами?
Всё зависит от того, что у вас на сервере стоит. Например, если Memcache установлен, то можно просто установить модуль Memcache API and Integration (https://drupal.org/project/memcache), что может существенно снизить нагрузку.
Я не знаю как делается корзина с использованием Views, но мне кажется, что кэширование будет вызывать глюки. Хотя, лучше протестировать.
---------- Добавлено 31.07.2013 в 20:43 ----------
forest25:
Хотел попробовать Booster, но не знаю как он себя поведет на интернет-магазине где нужен интерактив от пользователей.
Может Boost? Каким именно действиям пользователей он может помешать? Я использую Boost на сайте интернет-магазина (Ubercart).
DenisVS: Ситуация. Одинаковые views на разных сайтах. Включаю кэширование на одном — всё работает, при любых установках. Включаю кэширование на другом — ничего не отображается, при любых таймаутах. Имеется в виду кэширование самой вьюхи в Advanced. Возможно, разница настроек серверов, т.к. на разных хостах, ещё не проверял.
Тут тяжело что-то сказать. Можете попробовать сбросить кэш в Drupal. Если не поможет и вы уверены, что перестаёт отображаться именно из-за включения кэша, то я бы шаг за шагом отследил бы откуда берутся данные для вывода (нужно разместить dpm() или print_r() в нескольких местах в коде модуля, чтобы понять где именно пропадают данные). Также рекомендую посмотреть в лог ошибок.
DenisVS: furamag, в итоге да, так и сделал. Но ведь хочется большей гибкости. Пока не додумал, но ведь может эта вьюха быть завязана на что-то, и, чтобы не лазить-править везде лучше переключить в одном месте. Точно, модуль просится.
Не получится такой модуль сделать. Вьюха может быть завязана где угодно: в настройках, в коде модуля, в коде темы и т.д. Такому модулю нужно будет иметь информацию о всех остальных модулях, чтобы менять имя вьюхи в других модулях, когда кто-то меняет его в админке. Это касается не только модуля Views, но и любого другого элемента системы, где что-то привязывается к уникальному id.
DenisVS: Как поменять машинное имя view? Здесь думали-думали, и без ковыряний базы не придумали. Сказали, создавайте новую вьюху с нужным именем и не парьтесь.
А чем вам не подошёл вариант с экспортом/импортом? Это же одно и то же. Просто нужно старую Вьюху удалить потом.
ivan-lev: А Вы пробовали? Если да - с удовольствием ознакомлюсь с рабочим вариантом. Возможно, есть галка/настройка/опция... Или куча дополнительных модулей.
Так вроде бы обычный Exposed Filter добавить для какого-то поля и выбрать Operator = Contains. Вот, что у меня получилось в запросе:
Ясно теперь.. Фантазировал, как Boost будет интернет-магазин ускорять, для уверенности на страничку заглянул в схемку - мало ли, вдруг изменилось чего...
Просто в моём понимании, это своего рода баг системы. Наличие сессии не значит, что пользователь залогинен. Информация о товарах в корзине хранится и для анонимных пользователей. Могут ещё многие вещи хранится в сессии. Поэтому я и удалил условия в ядре, которое проверяет наличие сессии. Это обсуждалось уже на drupal.org. Я так и не понял, что они там решили.
Скорей всего я просто не понял, сайт без CMS.
Если сайт без CMS, то только разработчик скрипта знает, где прописываются логин и пароль. Нужно найти откуда скрипт берёт данные, которые использует в mysql_connect().
Скорее всего, прописаны неправильные логин и пароль для MySql в настройках CMS/скрипта.
«дополнительных модулей кэширования» - вот тут хотелось бы поподробнее. Какие из них реально помогают, а какие глючная поделка?
Всё зависит от вашего сайта. Я использую Block Cache Alter (https://drupal.org/project/blockcache_alter) и Entity cache (https://drupal.org/project/entitycache). Плюс настройка кэширования блоков в Views. Вам могут помочь и другие модули, но сказать какие именно не могу, так как это зависит от конфигурации и функционала сайта.
Да, точно Boost =)
Ну вот та же корзина к примеру. Например сгенерилась страница каталога и закешировалась полностью. Пользователь закинул товар в корзину, но кол-во товаров отображается прежним т.к. страница снова отдалась из кеша. Я про такого плана возможные косяки.
Я для корзины использую Ajax Blocks (https://drupal.org/project/ajaxblocks). Он подгружает блок с корзиной через Ajax. Вся остальная страница остаётся закэшированной через Boost. Правда, мне пришлось ядро Drupal пропатчить, так как он не даёт создавать кэш страницы, если сессия содержит какие-то данные.
Делал не я. Сайт мне уже достался таким. У меня другое мнение насчет скорости его работы.
Есть что сказать по существу? В плане действий по оптимизации.
Ставите Devel, смотрите запросы к базе данных для каждой страницы и выясняете что именно даёт нагрузку. После этого пытаетесь понять как оптимизировать нагрузку. Ряд запросов можно убрать путём установки дополнительных модулей кэширования. Некоторые запросы можно убрать какими-то простыми действиями (загрузка более новой версии перевода и т.д.).
---------- Добавлено 31.07.2013 в 20:39 ----------
Ребят, подскажите плиз варианты по оптимизации скорости Drupal Commerce?
Настройка серверного ПО не в счет, интересуют именно варианты справильной настройкой кэширования, установкой доп. модулей и т.д.
Алсо, корзина сделана на views. Можно ли там включать кэширование или будут глюки у покупателей с товарами?
Всё зависит от того, что у вас на сервере стоит. Например, если Memcache установлен, то можно просто установить модуль Memcache API and Integration (https://drupal.org/project/memcache), что может существенно снизить нагрузку.
Я не знаю как делается корзина с использованием Views, но мне кажется, что кэширование будет вызывать глюки. Хотя, лучше протестировать.
---------- Добавлено 31.07.2013 в 20:43 ----------
Хотел попробовать Booster, но не знаю как он себя поведет на интернет-магазине где нужен интерактив от пользователей.
Может Boost? Каким именно действиям пользователей он может помешать? Я использую Boost на сайте интернет-магазина (Ubercart).
Ситуация.
Одинаковые views на разных сайтах.
Включаю кэширование на одном — всё работает, при любых установках.
Включаю кэширование на другом — ничего не отображается, при любых таймаутах.
Имеется в виду кэширование самой вьюхи в Advanced.
Возможно, разница настроек серверов, т.к. на разных хостах, ещё не проверял.
Тут тяжело что-то сказать. Можете попробовать сбросить кэш в Drupal. Если не поможет и вы уверены, что перестаёт отображаться именно из-за включения кэша, то я бы шаг за шагом отследил бы откуда берутся данные для вывода (нужно разместить dpm() или print_r() в нескольких местах в коде модуля, чтобы понять где именно пропадают данные). Также рекомендую посмотреть в лог ошибок.
furamag, в итоге да, так и сделал. Но ведь хочется большей гибкости. Пока не додумал, но ведь может эта вьюха быть завязана на что-то, и, чтобы не лазить-править везде лучше переключить в одном месте. Точно, модуль просится.
Не получится такой модуль сделать. Вьюха может быть завязана где угодно: в настройках, в коде модуля, в коде темы и т.д. Такому модулю нужно будет иметь информацию о всех остальных модулях, чтобы менять имя вьюхи в других модулях, когда кто-то меняет его в админке. Это касается не только модуля Views, но и любого другого элемента системы, где что-то привязывается к уникальному id.
Как поменять машинное имя view?
Здесь думали-думали, и без ковыряний базы не придумали. Сказали, создавайте новую вьюху с нужным именем и не парьтесь.
А чем вам не подошёл вариант с экспортом/импортом? Это же одно и то же. Просто нужно старую Вьюху удалить потом.
А Вы пробовали? Если да - с удовольствием ознакомлюсь с рабочим вариантом. Возможно, есть галка/настройка/опция... Или куча дополнительных модулей.
Так вроде бы обычный Exposed Filter добавить для какого-то поля и выбрать Operator = Contains. Вот, что у меня получилось в запросе:
Это то, что вы искали?
"Правильный" поиск по подстроке "LIKE '%$search%'" на Drupal.
Есть "красивая" реализация?
Не интересует:
- с использованием сторонних средств: сфинкс, solr
- с использованием fuzzy, porterstemmer
А через модуль Views не пробовали сделать поиск? Он вроде бы делает правильный поиск типа "LIKE '%$search%'". Если пробовали, то что не устраивает?