rb2

См. начало треда. Может и решали, всего ведь не упомнишь. Тут или поиски и самообразование, умноженное на стоимость вашего часа, или к специалистам.

Ускорители обычно занимаются кешированием каких-то проблемных мест. Они могут снизить количество запросов. Сами запросы при этом останутся какими были, просто реже вызываться будут. На какое-то время (может и продолжительное) кеширование спасёт от повышенной нагрузки, но медленные запросы никуда не денутся. При дальнейшем росте ассортимента магазина рано или поздно вы опять упираетесь в то, что старый 2-сек запрос выполняется уже 5, а то и 15 секунд, когда до него дело доходит. А потом ещё оказывается, что посещаемость-то выросла, и случаются ситуации коллизий, когда что-то лочит таблицу и массивный, но в общем-то выполнимый запрос начинает выполняться по 40-60-80 секунд и до конца не доживает, так как его прибивает что-то из следящих за пожирателями ресурсов сервисов и отправляет отчёт root-у вашего хостера. Который даёт вежливых пендлюлей вам и грозит в случае неустранения ошибок поставить жёсткое кеширование (когда до реальных запросов дело вообще доходит раз в сутки, например, и обновление вам неподвластно). Анализировать и менять проблемные запросы не так просто, как может показаться: некоторые из них растянуты на многие экраны кода и перемешаны всякими условиями, модифицировать их корректно - иногда весьма мозголомная и кропотливая работа. С другой стороны, оптимизация запросов решает очень многие проблемы кардинально. И многоминутные стандартные сайтмапы вдруг генерятся за секунды, и стоявшие кешеры иногда приходилось отключать, потому что толку ноль - без них скорость такая же, а кеширование иногда мешает. Так что проще-то оно может и проще, но со своими плюсами-минусами и последствиями.

Тормоза от пробелов в именах файлов? Это что-то новенькое.

Это информация от Casio или от основного и единственного в РФ? Не нашёл на сайте Casio подтверждений. Зато нашёл список сервис-центров: www.support.casio-europe.com/ru/servicecenter/watch/ Чтоб дистрибьютор был единственным и при этом не значился как сервис-центр - настораживает. Повторюсь - начните с Casio. Спросите у них.

Конечно, можно кучу улучшений внести в движок. Десятки узких и кривых мест давно известны. Но тут дилемма - надо или уговорить DK их принять и включить в апстрим, либо забить на кучу пожеланий с "+1" на первой странице этого топика. Переделать предложенным способом вывод шаблона и говорить после этого о надеждах на совместимость с шаблонами и модулями от опенкарт никто же наверное не будет? Это в том варианте, о котором я говорил. Построение страницы товара (например) из множества отдельных модулей (таких, как переключатели валют и языков).

Да. Вот я и говорю - сделайте любым из доступных способов: категориями, тегами, фильтрами (встроенным или сторонними), да хоть вручную в "статьи" ссылок накидайте. Да. С чего бы это? Куда напишете - туда и ссылается. См. п.1. Пройдитесь по всем своим доскам сосновым и пропишите у всех одинаковый тег. Кликните по нему, скопируйте ссылку и вставьте баннеру в админке. Но завтра вы ж захотите заняться продвижением этой страницы и обнаружите, что у тегов и поиска нельзя задать title/h1/met-description/meta-keywords, поэтому я перечислил другие варианты. Есть немного.

Думаю, название официального регионального дистрибьютера на сайте Casio было бы достаточно. Зашёл на world.casio.com, оттуда - Европа, там Россия. В информации о компании и подразделениях не нашёл ничего про официальных представителей. Попросите у них подтверждения, является ли ваш поставщик их официальным дистрибьютором. Судя по сайту, у них там есть кому общаться на русском.Поиск по слову "официальн" даёт только одну ссылку на новость 2013 года про "Лит трейдинг". Поиск по "Санкт" даёт две ссылки, одна из которых (www.casio-europe.com/ru/emi/buy/) содержит предупреждение "Внимание! Остерегайтесь магазинов с нелегальной продукцией! Подробнее" и список десятка интернет-магазинов, вторая - про "G-SHOCK SESSIONS - это временные магазины (pop-up store), которые планируются к открытию в ключевых для уличной культуры местах европейских столиц", которая была в Спб 7 июня 2013. Так что задайте вопрос официальному русскому Casio. Может узнаете что-нибудь новое про своего поставщика.

Ну это вообще не те количества, чтобы что-то замечать. Если заметны какие-то лимиты уже сейчас - это и вправду повод задуматься о более гуманных хостерах. Я видел и 30к товаров, которые неплохо себя чувствовали при неоптимизированном опенкарте на обычном шаред хостинге, но уже начали получать предупреждения о повышенной нагрузке и медленных запросах, и опенкарты с парой-другой тысяч - даже не знают и не могут найти у другого хостера индикатор загрузки или какие-то лимиты в описании тарифных планов. Это всё обычный шаред хостинг за 2-3-5-10 долларов в месяц. Но и не повод не заниматься лечением. Просто перекладывать магазин на более мощный хостинг - это способ продлить агонию или сделать болезнь незаметной. Даже если через какое-то время перестанет расти кол-во товаров, категорий, атрибутов, опций - будет расти посещаемость. Всё равно рано или поздно придётся идти за оптимизацией. Ко мне, Снастику, к гуглу... Поставьте https://opencartforum.com/files/file/786-db-log/ - он элементарно ставится (распаковать и дописать 4 буквы в одном файле) и даст хоть какую-то реальную пищу для размышлений оптимизатора. Пока у вас не будет лога медленных запросов и детекта тормозных мест - будете заниматься гаданиями, а не двигаться в сторону лечения.

А при чём тут быстродействие? DK никогда это не заботило - он, например, и про индексы в базе с пренебрежением отзывался, и долгое время публично тупил и обзывал умных людей идиотами, когда ему про составные индексы рассказывали.Да и сменили не только шило на мыло, а синтаксис. И если бы не упёртость некоторых очень уважаемых разработчиков - OCMOD ещё долго оставался бы "vQmod-ом для бедных", как его прозвали поначалу. Но сейчас вполне терпимо.

Попробуй.Я тоже такой умный был - погугли мои посты здесь за 2011 год. Там чуть ли не слово в слово будет то же самое. Я такое пробовал и при работе с языками, и свою модификацию с удобствами держать рядом в соседней ветке или соседнем репо. Итог? Я устал ежедневно по 10-50 конфликтов разрешать. У DK&Co нет ни какого-либо плана-роадмапа, ни культуры ведения совместной или публичной разработке, ни хорошего знания инструмента (гита). С их репо тяжело работать с удовольствием. На примере с языками - тоже замахался регулярно отслеживать изменения то туда, то сюда, и пришёл к выводу, что локализацию выгодней по времени делать один раз, а не регулярно мониторить. В теории оно всё хорошо должно работать. Но практика вносит существенные коррективы. Это не значит, что прям совсем нельзя и всё настолько плохо. Это как раз то направление, куда стоит стремиться. Просто при таком подходе маты в сторону DK будут нестись ежедневно, а не раз в полгода. Я проверял. Ок, заменили, подменили модифицировали. Модифицировали ДАННЫЕ. Некоторые из которых вопреки заветам - уже не просто данные, а с оформлением. Это решает часть проблемы. Причём мне кажется, что малую.Не решает проблему, когда что-то добавить надо в шаблон. То есть надо переносить формирование кусков шаблона куда-то наружу (в данные, передаваемые ему). Либо бить вывод страниц на мелкие модули: например, страница товара - не монолитная, а из кучки мелких модулей-дивов: заголовок, блок с ценой и атрибутами, блок с описанием, блок с картинками и т.п. Тогда рядом проще будет положить модифицированный аналог и переключить вывод на него. Но такой микро-модульный подход в архитектуре Опенкарта натыкается на проблему данных и количества запросов к базе. Спасибо, кэп. Но есть такое слово "надо".И вручную вносить правки - это только один из вариантов. Навязывать который конечному пользователю как единственный - не самая хорошая идея. Может у него как раз default шаблон или минимально отличающийся по структуре (а CSS-ом он натворил чудеса и шаблон не узнать).

Что-то мне кажется, что DNS запросы кто только не кеширует. Начиная от операционки и заканчивая броузером. Хотя врать не буду, не тестировал. http://compnetworking.about.com/od/dns_domainnamesystem/f/what-is-a-dns-cache.htm У меня сервер в 140 мс пинга от меня. Разница, конечно, видна при работе по SSH (между мгновенными 4-5 мс и моими 140), но в броузере - вообще незаметно. Keep-alive и кеширование кучи хлама (JS, CSS, картинок) не просто так же придуманы.

Вам нужно вылезть из исходников и заняться изучением админки. Баннеры настраиваются там, с картинкой и ссылкой. Баннер к странице привязывается через механизм схем (layous).

А в OC2? Там XML-ки в базу складываются. Но я подробно не вникал, другим сейчас занят. Для разработчиков есть возможность положить xml-ки в `system`, но это как вариант для отладки, чтобы не обновлять модификации при каждом изменении файла.Про vQmod уже можно забывать.

Патчи я и предлагаю для программистов. Проблему ocStore вижу в том, что здесь есть много хороших и грамотных решений, но пользоваться ими трудно. Как тем, кто пришёл с другим движком (нативным опенкартом) и не может от него взять и легко отказаться, а вынужден заниматься раскопками и догадками, так и команде - у которой весь опыт не накапливается в виде решений. И пофиг, в каком формате, если честно. Мне уютней сохранять наборы "diff + git-extract" (.diff и рядом папка со всеми изменёнными файлами) и работать с ними, кому-то нравится оформлять это в vQmod-ы, а в следующий раз распутывать в обратном направлении - пожалуйста. Ну и пусть себе лежат рядом. Но нужен механизм "магнитофона". Чтобы накопленные атомарные изменения были локализуемы и их можно было воспроизвести при работе над следующей версией сборки. Заходим в репо патчей предпоследней версии, делаем ветку для новой, берём по очереди, применяем. Есть конфликты - лечим. Будет там 50-100 папочек с патчами и разными вариантами исполнения - и замечательно. Кто захочет, возьмёт вкмод, кто-то предпочтёт файлы сравнить и перенести руками в свою сборку изменения. Тогда и над сборками станет легче работать. А опыт - накапливать. А не массивно впрыскивать изменения щедро по всему коду сборки. А через полгода чесать репу: опа, а теперь же надо собрать и вычленить снова всё, что мы туда нафигачили... А ведь делать это снова и снова - скучно, нунафиг. Так и живёт сборка от одного энтузиаста, которому больше всех надо, до другого. От Yesvika до Toporchillo. Которые устают обсуждать и решают просто сделать. Но хватает на пару-другую итераций и перегорают, ясен пень. Потому что выгоду от своих вложений получают лишь косвенную. Эта система пока неспособна решить проблему модификации шаблонов. Тут кроме OCMOD других вариантов пока нет.

Иногда нет выхода. Например, микроразметка. Надо модифицировать очень многие TPL-ки. XML -- 100 кило. Внутри файла почти 2000 строк. И что тут сделаешь? Простой пример: весь рунет поголовно хочет Title/H1/Meta-keywords для всех страниц. Чтобы их вывести, надо в т.ч. и шаблоны страниц менять для вывода новых полей или переделки вывода старых. Все опенкарт-шаблоны, разумеется, эту кухню поломают, поскольку не знают о ней. И их в любом случае адаптировать надо. У @snastik в OCSHOP-е этого ещё больше и гораздо более заметно, чем в ocStore. Как можно хотеть в таких условиях полной совместимости? Не будет её. Можно и нужно к ней стремиться. Но тут - или стремиться сохранить совместимость и вносить как можно меньше изменений (и как можно больше - внешними модулями, хочешь ставишь, не хочешь - не ставишь), либо забить и делать фичастую и удобную сборку. Которая будет удобная, но со своим локальным рынком сбыта и перепилов. Кстати говоря, оптимизация быстродействия также является тем местом, которое привносит много несовместимости со стандартными модулями.

Нету. Но и способа быть уверенным в порядке их выполнения в будущем тоже нету. Поэтому как разрешать конфликты двух модов, которые правят один и тот же кусок кода, я не знаю.

Да, это единственное известное мне преимущество vqmod-а в лучшую сторону. Не хотелось упоминать его, хотел посмотреть, кто из сторонников про него знает :) На практике -- проблем и возни с конфликтами вкмодов в разы больше. sv2109 уже достаточно расписал, я вряд ли смогу что-то добавить. Если уж что-то в файле поехало, то рассчитывать на то, что вкмод под прошлую версию опенкарта заведётся на новой без перепиливания, а сам всё найдёт -- ну, не знаю... Я такого и не видел никогда. Зато как ни увидишь вкмод у клиента - знаешь стопудово, что лог ошибок там минимум на несколько сотен килобайт (а обычно гораздо больше -- от десятков мегабайт в лучшем случае). И то "то у меня не работает", то "тут появилось, а тут нет, а должно". И ходи ищи в этом винегрете перепутанном, где чьи хвосты, наполовину они применились или полностью, и тот ли кусок кода нашли или попали в закомментированный продублированный кусок, а не в рабочий код. А уж как вкмоды запросы модифицируют - это вообще радость на всю голову, когда приходится во всей этой каше разбираться. Без гарантии, что следующий залетевший дятел не разрушит цивилизацию.

Наверное. И скорей всего не одно и даже не десять. Давно не интересовался. Навскидку: http://msysgit.github.io/ http://gnuwin32.sourceforge.net/install.html / http://gnuwin32.sourceforge.net/packages/diffutils.htm и ещё были раньше какие-то варианты, добавляющие в виндовс командную строку линукса и тучу мелких утилит - типа регэкспа, diffutils и прочего. Ещё всякие мержилки-сравнивалки файлов, бывает, прекрасно берут на вход diff и применяют его, и сделать diff могут. Какая там самая известная и популярная софтина под виндовс для этого... WinMerge кажется. Про неё мне кажется, говорили. Нашёл не её, а ещё одну: TortoiseMerge. Но по скриншотам - очень похоже и в тех же местах искать в WinMerge. http://stackoverflow.com/questions/517257/how-do-i-apply-a-diff-patch-on-windows

По какому ещё дефолту? Баннерам вы сами ссылки прописываете. Делайте как угодно - фильтром, категориями, тегами, поиском, и выводите.

Все стандартные способы уже описаны несчётное количество раз. Дальше всё индивидуально плюс опыт. Где-то индексы, где-то модули, где-то их можно убрать, где-то нужны позарез, где-то запросы оптимизировать надо, где-то может спасти кеширование. Если интересует платная помощь - обращайтесь, занимаюсь оптимизацией. Скажите хотя бы, на каких количествах товаров и категорий это происходит, используете ли модули фильтров, случайных товаров? Если используете что-то вроде случайных товаров - отключите, проблема давно известная. Также подсчёт кол-ва товаров в модуле категорий и меню (отключается в админке).

Поясните.

Открывайте лог ошибок веб-сервера и смотрите, что там написано при заходе на "белые страницы". https://opencartforum.com/forum-12/announcement-1-ошибка-http-500-internal-server-error-она-же-белый-экран-читать-прежд/

Ага. Положить патч в корень и применить командой `patch -p1 fix.diff` нереально сложно. И хранить набор патчей в формате diff гораздо сложнее, чем набор патчей в формате xml. Убрать патч из кода командой `patch -R fix.diff` или какой-нибудь `git revert 328473afdc` тоже гораздо сложнее, чем убрать xml. vQmod/ocmod - рантайм решение. Пусть и с низкими накладными расходами при использовании кеша. vQmod вызывается и проверяет, что ему выполнить, при каждом просмотре страницы. Я из тех, кому непонятно: зачем нужно вводить лишнее звено, если то же самое делается без дополнительных костылей (а технологии внесения и убирания этих изменений существуют уже лет 40 и протестированы не одним поколением программистов).

Формат изображений - JPEG? Попробуйте PNG.

https://opencartforum.com/files/file/526-attribute-category/ https://opencartforum.com/files/file/525-attribute-select/