sazonoff

о, пусть должно. можно код написать для этого. Напишите сами или закажите. Вариант?

@Nairi , а зачем пишите в чужой теме? это всегда самое супер-правильное решение. А заодно и сервер оптимизируйте.

разумнее всего

полезно начинать поиск проблемы с чтения логов. Там же написано почему именно.

полезно переводить гуглом, например сперва.

очищайте системный кеш тоже. может быть у вас еще и vqmod стоит. его кеш тоже надо.

использовать другой фильтр. разве не вариант?

почему вы так решили? робот не будет бесконечно ждать пока страница даст ответ. может выкинуть из-за этого тоже.

по хорошему это так. но на работу не влияет. но лучше избегать такого стиля. проверьте владельца папки и права на запись. учтите, что скрипт может работать от иного владельца чем владелец файлов по фтп. универсальный способ - это выставить права 0777. Но не очень правильный.

Метрика серьезно тормозит страницу. особенно с включенным вебвизором. в режиме смартфона гугл pagespeed всегда ругается на нее.

Вы не путайте с единицами в CSS. Там другое. а тут по сути размер для картинки в файле.

в движке нет такого. Это кверху ногами изображение? Даже шаблоны такое не делают. Им это без надобности. Где вы такое нашли? С чем боретесь то? Лучше покажите ссылку на страницу и объясните, что хотите. в писелах. а разве бывают варианты? это же абсолютные значения для изображения, его файла если быть точнее.

еще как вариант: вместо // Output $response->output(); делаем в system/framework.php // Output $response->output($registry); соответственно в response.php Но лучше сделать через дополнительное свойство $route к классу Response. Делаем, например class Response { private $headers = array(); private $level = 0; private $output; public $route; в system/framework.php добавляем строку: $response->route = empty($registry->get('request')->get['route']) ? null: $registry->get('request')->get['route']; $response->output(); а в самом классе Response используем: var_dump($this->route); Обошлись без глобальных переменных. И удобно сделать через ocmod без боязни, что ocmod сторонних авторов что-то испортит или мы испортим им. Т.е. максимальная совместимость будет. Можно, конечно, и через private переменную с публичным методом, но это уже не суть.

как вариант. правда, неэлегантное решение получается.

и тем самым поломали совместимость модулей, которые делались для 2.3. Теперь они не подходят под 3.0. Стоило ли такое хотение или нехотение разработчиков поломки совместимости? Я не могу понять, что же такого интересного появилось в 3-ке, что из-за этого можно было похерить совместимость с модулями от 2.3? На одной стороне куча наработанных модулей для 2.*, а на другой - что? я это и предполагал. непонятно только чего этим добиться хотели то? Повысить безопасность? Это сомнительно, т.к. все данные из config.php остаются доступными в глобальной области видимости, и этих данных достаточно чтобы получить доступ к чему угодно. Хотите доступ к БД? Пожалуйста! А в ней все на свете настройки и доступы есть. Так смысл изолировать $registry? Ведь в общепринятых практиках программирования он именно глобальный.

я знаю как это происходит в 1.5 и в 2-ке. Надеялся, что подскажут, что же изменилось в 3-ке. на каком этапе и зачем удаляется $registry? Где-то в середине скрипта $registry доступен, а потом исчезает. Так только в 3-ке. Я вообще не понимаю для чего нужно было делать такую несовместимость с 2-кой? Уже привык к $registry, а тут сюрприз. Такое впечатление, что главный конструктор выдумывает несовместимости и берет их с потолка. вот зачем переименовал token в user_token? Ничего кроме несвоместимости не получили.

нет. получите в 3-ке из библиотеки, например, response.php. В 2-ке и в 1.5 - без проблем. в 3-ке не получается. echo "==registry=="; global $registry; var_dump($registry); echo $output; так тоже самое var_dump($GLOBALS['registry']); Заметьте, что это происходит уже перед самым последним шагом, который делается, т.е. перед финальным echo $output; Куда исчез $registry?

$registry нужно чтобы получить route. в опенкарт 2 объект $registry - глобальный и везде виден, если не ошибаюсь. как в опенкарт 3 увидеть из любого кода $registry? Цель - получить route из любого кода. Если не через $registry, то как иначе?

однозначно, проблема в руках. на апачи не должно быть проблем даже при отсутствующем htaccess. вот без него и нужно сперва проверять. фактически он только на чпу влияет, а с отключенным чпу можно тестировать сайт без htaccess

как в opencart 2 и 3 из любого места кода получить route? имеется ввиду во это: $this->request->get['route']; Как, например, из своей библиотеки, т.е. там, где $this не работает получить значение route? В opencart 2 есть глобальная переменная (объект), которая видна везде - это $registry, можно через нее. В opencart 3 глобальная $registry уже недоступна. Так как правильно вытащить route? Как получить первичный route - это понятно, он легко берется из запроса сервера, но если работает ЧПУ, то route в итоге будет другой. Вот нужен этот конечный route, который и есть: $this->request->get['route'];

Отказываться не стоит, все же пользы от этих метрик гораздо больше чем вреда. Тем более, что возможности настройки достаточно широкие и вы можете ограничивать передачу информации в метрики т.п ищите компромисс.

Вряд ли им нужен такой бизнес. Репутацию на раз потеряют. А рег.ру - один из самых паршивейших хостеров по неадекватной качеству цене. Поддержка слабая, софт годами не обновляют на шаред-хостинге. Выезжают в конкурентной борьбе только за счет того, что первыми предлагают свои услуги новичкам, которые зарегали домен.

на 2.3 лучше. наверное ошиблись с номером версии. сайт, который сейчас на 1.5 глянуть получится?

Верно. Но все почему то забывают об этом. вот бедные. ради прикола глянул ebay. даже не в желтой зоне. 54/100 гугел выдал им. красная зона. отстой, выходит, этот ваш ebay с амазонами.

а чем они вам мешают? На ранжировании поисковиками никак не сказывается. Ну разве что чисто из стремления к недостижимому идеалу это сделать? Выше правильно вам намекают.