Yesvik

Нет такого. Я делал на поддоменах и правил что-бы при смене языка менялся поддомен.

https://opencartforum.com/topic/4740-%D0%B0%D0%BB%D0%B8%D0%B0%D1%81-%D0%B8%D0%BB%D0%B8-%D0%BF%D0%B5%D1%80%D0%B5%D0%B0%D0%B4%D1%80%D0%B5%D1%81%D0%B0%D1%86%D0%B8%D1%8F-%D1%87%D0%B5%D1%80%D0%B5%D0%B7-htaccess/

Да, позиции просядут.

Всё абсолютно верно. У тебя настроена переадресация и при запросе по адресу электрони.рф в ответ летит статус 301 который означает что документ навсегда перемещён по такому-то адресу. А как по другому? Чтобы в поиске светились оба адреса?Поисковики будут видеть одинаковый контент по разным адресам и я думаю ты понимаеш что ничего хорошего в этом нет. Ты застолбил домен электрони.рф, настроил переадресацию... что ещё ты хочеш получить от электрони.рф? Моё мнение по поводу кириллических доменов - это бред и развод на бабло. Причем развод на бабло касается известных сайтов и бреднов которые вынуждены выкупать свои кириллические домены, а остальные сами себя развели абсолютно добровольно... Спорить на эту тему не буду, так что можеш не отвечать... я просто обозначил свою позицию по этому вопросу и своё мнение не навязываю.

Ерунда полная. Большинство дополнений не улучшает код, а расширяют функционал... при этом эти расширения функционала сами требуют улучшений кода... Похоже ты не отдавал код... и не наблюдал как у них межу собой идёт срач... один включает, другой удаляет...И на этом форуме и на opencart.com периодически появляются интересные решения, возьми какое-то решение и попробуй продавить его в SVN. Когда сделаеш это - будеш писать про гордость и о том что это просто...

Лимиты там как раз есть... по крайней мере по памяти режут как дети в школу...Но ты так и не озвучил цифры... Сколько категорий, сколько уровней, сколько товаров... Небольшой разбор полётов: Про штатный генератор я вообще молчу... но и тот что ты используеш не фонтан... Вот это полное безобразие private function getCategoryPath($category_id = 0, $path = '') { $query = $this->db->query("SELECT c.parent_id FROM " . DB_PREFIX . "category c WHERE c.category_id = '" . (int) $category_id . "'"); if ($query->rows) { foreach ($query->rows as $category) { if ($category['parent_id'] != 0) { $path = $this->getCategoryPath($category['parent_id'], $path); } else { return $category_id; } } } return $path . '_' . $category_id; } Давай считать... Если у тебя 18000 товаров равномерно распределены примерно по 100 товаров в категории - тогда у тебя должно быть порядка 180 категорий. Не будем рассматривать кошмарные сценарии с каталогами в 10-15 уровней и будем считать что у тебя категории построены в три уровня и равномерно распределены примерно так: Первый уровень 5 категорий, каждая категория первого уровня содержит 5 категорий второго уровня и аналогично категории второго уровня содержат по 5 категорий третьего уровня... Получается 5 + 5*5 + 5*5*5 = 155 категорий... это меньше 180 но так считать проще. Алгоритм который я привёл из твоего генератора сделает 5 запросов на первом уровне, 50 на втором уровне и 375 на третьем уровне... Итого: 430 запросов - и это на трёх уровнях. У меня на 1000 категорий до 12 уровней этот алгоритм дал около 8500 запросов Всё тоже самое можно сделать одним запросом... На тестовой базе в 1000 категорий, 12 уровней, 10 000 товаров - алгоритмы из твоего генератора на шаред хостинге не смогли вывести даже категории. Переписал формирование категорий и товаров, изменил таблицу с алиасами и сайтмэп начал сносно генерится. Для вывода категорий и товаров из тестовой базы выполняется 9 запросов (это на локалке), на тестовом хостинге возможно чуть больше запросов - движки немного отличаются... Один запрос на категории и один на товары... ни кеш ни запись в файл вообще не используются. Так что подобные, рекурсивные алгоритмы, надо везде клещами вырывать и тогда всё будет работать и на шаред хостингах.

А по какой причине сдыхает на 3тыс+ ? И какое максимальное время генерации считаеш приемлемым?

В конце файла catalog\view\theme\default\template\product\category. tpl находиш строку display('list');и меняеш вот так display('grid');

Расписал всё правильно, только забыл написать что это для ocStore версии 0.2.x

Думаю что поле пароль заполняет не движок, а браузер... так как ему сказали запоминать пароли...Движок даже если бы хотел заполнить поле - не смог бы этого сделать потому что ему пароль не известен.

Задай вопрос автору сборки

Я не использую для профилирования MySQL Administrator. Это всётаки инструмент для наблюдения/управления MySQL сервером в целом. Мне гораздо удобнее использовать SET PROFILING_HISTORY_SIZE = 100; SET PROFILING = 1;

Из всех перечисленных ссылок только index.php?route=common/home доставляет реальные проблемы, остальные ссылки - это чисто вопрос эстетики. Убрать index.php?route=common/home можно вручную перелопатив кучу файлов, а можно поступить вот так http://opencartforum...dpost__p__24741 Изменять остальные ссылки особого смысла не вижу, но если очень хочется то поищи на форуме... предлагалось много различных вариантов.

Никакого тайного смысла нет. Просто многие не понимают что такое путь в файловой системе, а свой домен знают все.

Надо заменить свои конфиги на те что я выложил и в этих конфигах вместо domain.tld прописать свой домен. admin123 подставлять никуда не надо.

Вот файлы в которых всё расписано под наиболее распространённые модули... Правда это всё работало вместе с SEO URL Manager, но думаю без него тоже будет работать... seo_url.php seo_url.php

Пару раз приходилось opencart апдейтить на ocstore... набросал скриптик что-бы не изголяться с дампами dbconvert.php

Что такое "Category for Information Page" и какие рекомендации при подключении к стандартному SEO URL?

Да.Я не так давно познакомился с Opencart и на момент знакомства актуальная версия была 0.1.9 Так что по поводу 0.1.5 ничего сказать не могу, но решил предупредить что ты хочеш апдейтится не на последнюю версию. Что не так?

Вообще то уже давно вышел ocStore v0.2.2

Да... это я погорячился... Надо взять модуль из предыдущих версий..

https://opencartforum.com/topic/3673-ocstore-v101-rc1/page__view__findpost__p__24909

Начал просматривать форум и тут же наткнулся на типичную ошибку... http://opencartforum...age__pid__32286 Человек хочет отключить вывод количества товаров в категории и ему рекомендуют убрать вывод количества, а то что количество товаров при этом будет рассчитываться никого не волнует... Посмотрите на последний скрин в посте https://opencartforum.com/topic/4966-%d0%ba%d0%be%d0%bb%d0%b8%d1%87%d0%b5%d1%81%d1%82%d0%b2%d0%be-%d0%b7%d0%b0%d0%bf%d1%80%d0%be%d1%81%d0%be%d0%b2-%d0%ba-%d0%b1%d0%b4/page__view__findpost__p__32290 там 63 запроса которые выполняются для подсчета количества товаров в категории. Если отрубить не просто вывод, а не подсчитывать количество товаров - то из 182 запросов останется 119. Я при оптимизации очень часто сталкиваюсь с тем что готовится куча данных которые ни как не используются... Про некоторые дополнения я вообще молчу.... даже среди платных есть чудные... Но это уже не к разработчикам OpenCart...

Я устал спорить и объяснять что надо рехтовать оригинальный OpenCart... и не я один писал о рекурсивных выборках, но в ответ сыпались только крики о том что надо только переводить... Переводить - так переводить. Не хотели оптимизацию на шару - значит будет за деньги. Меня это устраивает.

Оптимизируем выборку категорий из базы без использования кеширования... только за счет алгоритма без рекурсивной выборки из базы... Главная страница с включенными категориями без SEO (102 запроса) Главная страница с включенными категориями с SEO (235 запросов, без оптимизации было 349) Страница категории desktops c SEO (287 запросов, без оптимизации было 410) Видно что даже при небольшом количестве категорий рекурсивная выборка даёт кучу запросов, а при большом количестве категорий - вообще кошмар... По скринам видно что много запросов даёт SEO. Прикручивать SEO PRO к OpenCart'у лень, поэтому выкладываю скрин вывода категории desktops с включенным SEO PRO и построением URL товаров с учетом категорий в ocStore из репозитория (rev.293) с аналогичной оптимизацией выборки категорий Так как SEO PRO кроме более оптимального алгоритма использует кеширование - даю два скрина. Холодный старт (пустой кеш, 229 запросов, с обычным SEO было 287) Повторный вывод (с кешированием SEO, 182 запроса, с обычным SEO было 287) За счет простейшей оптимизации одного алгоритма удалось избавится от 123 запросов (410 - 287 = 123) За счет использования SEO PRO избавились ещё от 105 запросов (287 - 182 = 105) Итого: 123 + 105 = 228 запросов. Если выполнить оптимизацию всех алгоритмов - то количество запросов будет как в посте http://opencartforum...dpost__p__32139 (там кстати SEO PRO не использовалось... так что можно продолжать оптимизировать.)