snastik

Курите матчасть! СпИцИалист по оперкарт. Тегов нахренячили модулем usergio и привет! А в роботсе не закрыто!

4-6 секунд это тоже тормозит. Исправляется комплексом методов: Оптимизацией базы, заменой системного класса кеширования, установкой дополнительных кеширующих модулей.

Потому что это "глобальный контейнер", в который собирается набор экземпляров базовых классов, который уже передается в класс controller, из которого происходят все манипуляции контентом. Он как раз и собирается из базовых классов типа cache, url, cart и так далее. И до того пока он не соберется полная коллекция необходимых библиотек - для чего его передавать в системные классы ?

мде.... вы бы версию написали.... если у вас класс уже загрузился автолоадером то просто $calc= new Calc(); если нет: require_once( path_to_lib );

Тогда вам не нужен ваш экземпляр класса в глобальном контейнере $registry Вы просто можете его вызвать в нужном месте в классе Cart. С помощью простой конструкции. $this->load->library('calculators/testcalc'); $testcalc = New Testcalc(); И дальше к примеру. $cost = $testcalc->method($cost );

В каком месте вы его хотите получить ?

Индексы - это далеко не панацея. Вот тут подробнее:

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

А вы уверены, что product_id у вас приходит нормальный ? сделайте после этой конструкции $this->log->write("update .... ) и посмотрите что у вас пишет на самом деле. Я подозреваю проблема в том, что вы просто кривой айдишник передаете и он или нулевой или его нету. А про кеширование запросов в базу - чушь!

Смотрите в htaccess

user-agent: yandex-bot Disallow:/ .... index.php?route=feed/google_feed Allow:/ .... index.php?route=feed/yandex_feed Sitemap: ....feed/yandex_feed Это схематично конструкция. Синтаксис подправьте.

Вот там вам и надо удалять кеш! А фатальные ошибки - какого типа. Что-то вы накрутили лишнего. Кеш отключать категорически не рекомендуется, так как вас просто поисковики вышвырнут из индекса.

Либо запретить ему индексировать общую Либо отдать гуглу общую а яндексу яндексовую

Я пытаюсь сказать, что во все дырки затычке, иногда стоит быть тише. И выступат на родной варезопомойке с равными! Только вскрытие! Только хардкор!

Не снимает! Если криво настроен сервер! Не начинайте как всегда лить воду в уши!

Дальше реально гадание на кофейной гуще. Но все это лечится.

Нет не будет!

wait_timeout interactive_timeout в mysql А также время выполнения скриптов в php Обычно у хостеров на виртуальном хостинге время выполнения ограничено 10 минутами даже по cron. И да, если у вас скрипт работает так долго - это либо плохой скрипт либо очень медленный магазин.

Вашей беде есть таблэтка. Необходимо сконфигурировать mysql сервер и проставить индексы в базе. Стучите в личку.

Страшного ничего, но подобные заявки от хостера - это первый звоночек, что с ним пора расставаться.

"Из коробки" любые данные магазина храняться или в файлах или в базе данных. Сессии - это уникальный идентификатор посетителя, по которому система узнает его при открытии новых страниц или при последующих посещениях. Соответственно сессия - это небольшой набор данных, который необходимо где то сохранить. По умолчанию на хостингах сессии храняться в виде пачки небольших файлов в специально отведенной папке. Если трафик небольшой и правильно настроен сборщик мусора, который удаляет протухшие файлы сессий - не возникает никаких проблем. Но, если неправильно настроен сервер, или на нем большая нагрузка, или у сессий очень большое время жизни, количество файлов в папке с сессиями может быть несколько десятков тысяч и это может повлиять на скорость работы магазина. Почему это происходит? Это обусловлено особенностями работы linux с файловой системой. Если в папке много файлов, работа с ними замедляется, так как увеличивается время на поиск необходимого файла. Соответсвенно БЕГЕТу не выгодны проекты, которые активно используют сессии и хранят их в файловой системе, так как увеличивается в целом нагрузка на сервер и замедляется работа всех сайтов, которые он обслуживает. Для того чтобы исправить эту ситуацию, необходимо их вынести в какое-либо хранилище, которое не будет затрагивать работу файловой системы. Это может быть как база данных так и любое хранилище, которое использует память вместо файловой системы. В конкретном случае они предоставляют Redis. В других случаях это можеть быть memcache или APC, либо как я уже выше писал база данных. Кстати в Opencart 3.0 сессии по умолчанию храняться в базе. Попробуйте в htaccess добавить следующие инструкции, только адрес подключения к хранилищу, поменяйте на тот, который предоставит beget. php_value session.save_handler redis php_value session.save_path "tcp://localhost:6379/"

Спасибо. Но на самом деле - ни один шаблон не кеширует комплексно все данные станадартных модулей и целиком html страниц.

Для версии 2.3 модуль появится с выходом ocstore 3.0 Пока он доступен только в сборке opencart.pro

Это вас beget разводит на доп услугу - не ведитесь.

Очередная приблуда, которая потянет за собой вагон конфликтов! Сколько раз можно объяснять, не стоит лепить подобные велосипеды потому что а) добрая половина разработчиков не используют $(document).ready б) в зависимости от набора модулей в схемах в них присутствует динамическое подключение набора скриптов/стилей в) если бы пейсатели подобных приблуд внимательно смотрели в логику оформления заказов, то увидели бы там очень интересный механизм, когда на страницу оформления подгружаются не только данные, но и скрипт, который потом инициализируется на готовой странице, в итоге это все нагинается и перестает работать. Равно как в большинстве случаев отваливается добрая половина js-фукнционала. Автор конечно хитрит и пишет - мол "вам нужны навыки в работе со стилями и скриптами", но позвольте.. Если есть подобные навыки, то пожать и впихнуть основные скрипты стили в один - это дело получаса, без использования каких бы то ни было приблуд.