Dotrox

Тогда ищите не по ip, а по функциям, которые могут обращаться к внешним ресурсам: curl, file_get_contents, fopen.

1. Вы тему в неправильной ветке форума создали, у вас же версия 1.5.4! 2. Зачем вы в футер админки эту переменную влепили? Я об вот этой ошибке при входе в админку: Notice: Undefined variable: pagination in /home/m/mwspbnet/public_html/admin/view/template/common/footer.tpl on line 4 Эта переменная в футере, в принципе, быть не должна, а админка тут уж тем более не при чём. Для вашей версии образец надо здесь смотреть: https://github.com/opencart/opencart/blob/1.5.5.1/upload/catalog/view/theme/default/template/product/category.tpl

Номера и текст типа "Показано 21 из 100" (хотя это зависит от шаблона). Если ничего не выводится, проверьте шаблон категории. Если там вывод переменной $pagination есть, тогда смотрите контроллер категории. И не забудьте посмотреть сначала версию в кеше модификаторов. Возможно, это косяк какого-то модуля.

Alex1979, у вас пагинация вообще не выводится или там только одна страница? Если совсем не выводится, то надо таки проверить в category.tpl наличие её вывода: <?php echo $pagination; ?> Как это должно быть можно глянуть здесь: https://github.com/opencart/opencart/blob/master/upload/catalog/view/theme/default/template/product/category.tpl Если же пагинация выводится, но там только одна страница, а товаров в категории больше, то у вас проблема с подсчётом товаров в категории. Вы это к какому движку советуете? Точно не к ОК :) В ОК пагинация - это часть шаблона категории, а не футера.

Если совсем не происходит (то есть открывается старая ссылка), то убедитесь, как выше сказал chukcha, что у вас не используется nginx, иначе именно он отдаёт изображения и никакие правки в .htaccess ничего не дадут. А конфиг nginx, если у вас шаред хостинг, вы сами отредактировать не сможете. А RewriteBase вы зачем закомментировали? Эта директива как раз и указывает, что считать корневой директорией сайта.

Не совсем понятно, куда у вас сейчас редиректит. Там что, полный путь от корня сервера? У вас есть это: RewriteBase / Можно просто добавить полный путь с доменом в качестве целевого адреса: RewriteRule ^image/cache/data/(.+)$ http://domain.com/image/cache/catalog/$1 [R=301,L]

А я всё думал, вспомните вы про эти файлы или так и продолжите отмазываться в стиле "сам дурак" вместо приведения хоть каких-то аргументов. Да, эти файлы нарушают PSR-1, но это не повод делать то же самое! Кстати, в 2.3 в index.php единственным нарушением осталась константа с версией. Так что даже мега гавнокодер Дэниэль понемногу развивается :) Необходимость модификации файлов движка - в любом виде сама по себе является архитектурным гавнокодом. И пока вы и это не приняли, как личное оскорбление, уточню, что это критика не в ваш адрес, а в адрес существования vQmod/OCMOD, точнее - в адрес необходимости их существования. То есть, вы считаете, что за пределами архитектуры гавнокода не существует? Вот это по вашему не гавнокод: if($a < 0){ $a = $a * (-1); } Кстати, я этот код не выдумал для примера, а действительно видел в одной системе. Если вы считаете себя сеньором и архитектором, то назовите, какой паттерн используется в ОК помимо MVC? Я говорю про более низкий уровень абстракции, чем MVC. Сразу скажу, можете не гуглить - об этом нигде не упоминается, но для того, кто знаком с этим паттерном, его использование в ОК очевидно. И я не говорил, что архитектура не важна - важно всё. И если сеньор не уделяет особого внимания таким элементарным вещам, о которых мы тут уже две страницы спорим, то только потому, что для настоящего сеньора это на таком же инстинктивном уровне, как дыхание. Но вероятно, вы не знаете какого мнения профессионалы про сам ОК, иначе бы не прикрывались ним. Приходилось ли вам слышать, что код ОК - это шутка? Или что ОК пригоден разве что в качестве учебного движка для новичков, но никак не для реального использования в e-commerce? У вас кстати, много общего с Дэниэлем: он тоже когда слышит критику, начинает называть её авторов аматорами, которые ничего не понимают в программировании.

У вас на главной все изображения больше, чем размер для отображения. У товаров там разница вдвое. Учитывая, как медленно у вас сейчас грузится статика, это имеет смысл поправить. А с временем ответа сервера вообще творится что-то непонятное. Для главной минимальное время было 1 секунда (что довольно много), а максимальное - 24 секунды. Само по себе большое время ожидания ответа можно было бы объяснить разными причинами, но такие скачки указывают на проблемы с сервером. И на это же указывает медленная загрузка статики. Кстати, к вопросу качества шаблона - в Мозилле слайдер сходит с ума и начинает непрерывно загружать все изображения. Это всё не объясняет причину нехватки памяти, но тоже требует внимания.

Вижу, что это как раз вы не понимаете, что такое побочный эффект! Инклюд внутри класса (или функции) не является побочным эффектом, поскольку он там не выполняется в момент обработки интерпретатором кода декларации класса (или функции), а выполняется в момент вызова метода класса (или функции), который его содержит. Надеюсь, вы понимаете разницу между декларацией и вызовом? Потому что отсылки к engine говорят об обратном: вы считаете, что там есть нарушение этой рекомендации, но при этом там нет вызовов - только декларации. Кстати, по вашей логике получается, что само существование инклюда нарушает PSR-1, потому что любое его использование, по вашему мнению, - это уже побочный эффект. Собственно, суть этой рекомендации в PSR-1 как раз и заключается в том, чтоб не смешивать в одном файле код, который является декларацией и код который исполняется сразу же в момент прочтения интерпретатором. То есть, не смешивать декларации и вызовы. Лично я не чувствую разницу между "патчить" и "добавить пару строк". Я встречал модификаторы. которые добавляли всего пару строк - это значит, что это уже не патчинг просто потому, что только пару строк? И по поводу "не в код опенкарт" - вы всё равно модифицируете стандартный файл и не имеет значения в каком месте файла вы дописываете свой код. И потому это тоже тот случай, когда не обойтись без модификаторов. Кстати, я не знаю, каким именно образом работает ваш код, который инклюдится, но мне видится, что этот инклюд вполне можно было бы дописать в action.php перед $controller = new $class($registry); и это имело бы тот же эффект, при этом не нарушая PSR-1 и не требуя модификации каждого файла контроллера в отдельности (привет DRY). И чем это будет лучше окмода? В случае 1.5 и vQmod ещё можно сказать, что это не требует от пользователя устанавливать vQmod, но в двойке OCMOD из коробки, а потому нет смысла придумывать собственные велосипеды, которые делают то же, что и он.

Вот цитата оттуда: И ссылка на саму спецификацию: http://www.php-fig.org/psr/psr-1/ Покажите конкретный пример из ОК. Я такого там вспомнить не могу. Суть гавнокодинга как раз в том, что автор такого кода плюёт на любые рекомендации, которые напрямую не влияют на работоспособность кода! А все подобные спецификации не могут быть жёсткими требованиями, а не просто рекомендациями, поскольку они напрямую не влияют на работоспособность кода, а значит никто не может заставить им следовать. И кстати, обратите внимание, что в спецификации используется should, а не may или can, так что это всё же довольно настоятельные рекомендации! Я согласен, что из-за отсутствия в ОК нормальной системы расширений, для работы некоторых модулей неизбежно использование различных костылей, но эта неизбежность не делает такой код качественным. Если во время дождя вы прикрываете голову пакетом, потому что не взяли с собой зонт - это не превращает этот пакет в зонт. Кроме того, благодаря vQmod/OCMOD (которые сами являются костылями) есть возможность добавлять свой код практически куда угодно, а потому нет необходимости создавать костыли прикрываясь их неизбежностью - модификаторы позволят обойти нерасширяемость ОК без дополнительных костылей.

Да, с чётким выражением мыслей у вас явно проблемы. То что вы пытались сказать, называется - "не в классе контроллера", а не просто "не в контроллере", ибо слово контроллер в случае ОК обозначает и класс и его файл (в таких файлах всё равно больше нет ничего). Тем не менее, это файл контроллера, что всё равно противоречит архитектуре ОК, где действует принцип: один файл - один класс и ничего более (когда идёт речь о файлах с декларацией классов). И, что более важно, это также противоречит PSR-1 (если вы знаете, что это)! Если вы считаете, что нарушение спецификаций PSR не является гавнокодингом, то с вами, действительно, больше не о чем разговаривать.

Вы оцениваете мой уровень по количеству сообщений на этом форуме? Тогда, действительно, по сравнению с вами я даже не джун, а вообще младенец :) Использовать вместо опенкартовского лоадера прямой инклюд в контроллерах - это не архитектурная ошибка? Говоря про инклюд я сразу сказал, что это противоречит архитектуре ОК и вы так и не смогли показать хоть один контроллер в ОК, где подобное происходит, а loader.php, action.php и startup.php - никаким боком не контроллеры, а как раз те элементы архитектуры ОК, благодаря которым нет необходимости использовать прямой инклюд на более высоких уровнях. Если у вас есть необходимость в собственном лоадере, вы можете его подключить тем же образом, каким подключается оригинальный лоадер. Точка входа куда? Вообще, что является точкой входа зависит от конкретного языка и в случае php - это первая строка в первом файле вызова, но обычно в php точкой входа в приложение называют весь первый файл, то есть в случае ОК - это /index.php для витрины и /admin/index.php - для админки. А где тогда? В ошибках из первого поста, конечно, путь обрезан, но я не знаю в ОК других файлов с названием maintenance.php не считая языкового, но, если это вставка из языкового файла - это было бы уж совсем не смешно. Так что я уверен, что это файл /catalog/controller/common/maintenance.php.

В принципе, в ошибке сказано, что вам не хватило всего 512 байт памяти, так что исчезновение нескольких товаров из базы как раз и могло сократить потребление достаточно, чтоб уложиться в ваш лимит в 128Мб. Может, у вас какая-то экзотическая сборка? Кстати, хороший рейтинг шаблона указывает только на то, что он нравится покупателям, но никак не на его техническое качество. Дайте ссылку на сайт для начала. Что-либо ещё заочно посоветовать не получится.

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

Да уж, надеюсь, код вы пишите внимательней, чем читаете сообщения, на которые отвечаете. Что во фразе "прямой инклюд файлов в контроллерах" вам непонятно? Или вы не знаете, где в ОК контроллеры? Разве я что-то говорил о том, что инклюд как таковой - это плохо? Ну а по ссылке отлично видно, что на весь ОК инклуд есть всего в трёх файлах, где без инклюда или реквайра движок просто бы не собрался в кучу. Учитывая, что я не понимаю, как это относится к обсуждаемому коду, то, видимо, я интересовался не той защитой, о которой идёт речь.

При таком количестве товаров/категорий проблем возникать не должно, если у вас нет кривых модулей. А как изменилась база после отката? То есть, там стало меньше товаров/категорий или стёрлись настройки каких-то модулей (и они отключились)? Некоторые модули в ОК - это бомбы замедленного действия. Их авторы думают, что не существует магазинов, где больше сотни товаров (условно) и потому их модули не предназначены для нормальной работы с большим количеством товаров, так что когда количество товаров увеличивается, такие модули начинают внезапно ложить магазин. 1000 - это уже достаточное число, чтоб кривой модуль завалил магазин.

В данном случае речь идёт о бекапе базы - в нём должны быть не только данные, но и структура. Но раз зиливали в пустую базу (то есть, без таблиц), то структура была. А проблема возникла из-за того, что у вас на локалке другая версия ОК. Почему вы не залили на хостинг тот ОК, который на локалке? Удалите все файлы кроме конфигов и изображений с хостинга и залейте туда файлы с локалки. Поверх них больше ничего не заливайте.

1. Иконки: сейчас каждая иконка - отдельный файл, то есть на ровном месте возникает необходимость грузить десятки файлов вместо одного спрайта. 2. На главной переизбыток товаров (а точнее их изображений). Если вы хотите выводить такое количество товаров на одной странице, нужно организовать отложенную загрузку изображений для них (lazy load). 3. Не уверен, насколько в этом виноват шаблон, но время ожидания ответа сервера при первой загрузки какой-либо страницы в пределах 1.5 - 2 секунды, что и, в принципе, слишком долго и в случае ОК значительно выше нормы. Малое время ответа при повторном открытии страницы указывает на то, что проблема в базе (при повторном открытии данные берутся из кеша). И последнее: у вас почему-то на всех страницах грузится апи Яндекс.Карт. Саму карту вижу только в контактах, но апи грузится везде и сильно увеличивает время полной загрузки страницы. Ещё в список таких тормозов можно добавить виджеты Фейсбука и ВК, которых я на странице не вижу, но вижу, что они грузятся.

Будете отключать все части ОК, у которых возникнут проблемы из-за кривой базы? Как я уже писал выше, сделайте нормальный перенос (то есть, с переносом структуры), иначе вы ещё долго можете ловить подобные ошибки.

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

Если вы переносили полный дамп, такой ошибки возникнуть не могло. Вероятно, вы переносили только данные в уже существующую базу. Сделайте полный перенос (структура + данные), эта колонка может быть не единственной недостающей, остальное может всплыть потом.

Поискал: https://github.com/opencart/opencart/search?utf8=%E2%9C%93&q=include_once Это как-то противоречит моим словам? Действительно, что комментировать, если уже на include_once зафейлились.

Если б вы процитировали ту фразу из моего поста, на которую отвечаете, было бы проще понять, что вы говорите :) А по коду: начнём с этого "маркера" - смешно тут вспоминать о DRY, ибо он не о таких глупостях, но единственный смысл такого дублирования я могу предположить только в том, что с этой переменной происходит что-то внутри файла, который инклюдится, а её значение нужно ещё где-то дальше по коду текущего файла. И тут есть сразу два замечания: 1. Если с переменной что-то происходит внутри файла, то и восстановления её значения должно быть завёрнуто в тоже условие, которое подключает файл, иначе получается, что переменная устанавливается дважды одним значением независимо от того, использовалась ли она. 2. Но более важно то, что так вообще не делается! Если значение переменной нужно модифицировать в каком-то локальном скоупе, а затем продолжить использовать оригинальное значение в глобальном скоупе, то в локальном скоупе нужно скопировать значение в локальную переменную и делать с ней что угодно. Если же эта переменная вообще не работает, а только помечает этот блок кода, то это настолько противоречит здравому смыслу, что никто в здравом уме такого даже не предположит. Если есть необходимость пометить блок кода - есть комментарии. Нет необходимости засорять код элементами, которые не являются частью логики работы программы. Следующий пункт: судя по названиям файлов - это контроллеры. Дополнять код контроллеров вставками с php тегами - это уже само по себе, как минимум некрасиво (и нарушает стиль кодинга в ОК), но если эта вставка не в конце файла (а в конце файла нет смысла восстанавливать значение переменной), то эта вставка ещё и режет код контроллера на куски. И напоследок: прямой инклюд файлов в контроллерах противоречит и архитектуре ОК и современным принципам кодинга в целом.

Отключите подсчёт товаров в категориях для начала (в зависимости от версии и сборки отключения в админке может быть недостаточно).

Ну, исходя из этой логики в ОК бы вообще ресайза не было (а он есть не только в ОК). Представим страницу категории: надо показать полтора - два десятка изображений товара, размер для показа, например, 150*150, вместо этого мы заставляем грузить в размере 600*600, потому что в таком оно на CDN (или вообще 2500*2500). А размер прямо сказывается и на весе + ресайз средствами CSS в меньшую сторону приводит к эффекту перешарпленности (появление зазубренностей на контурах). Пока непонятна общая картина. Если CDN используется просто как дешёвое хранилище для больших объёмов, то вариант, который я описал выше - вполне подходит. Если CDN используется для ускорения загрузки изображений в браузер посетителей, то, конечно, посетителям надо грузить именно оттуда, но в сам CDN нужно заливать уже отресайзенные изображения (оригиналы тоже можно там хранить, но главное, чтоб там были и файлы после ресайза).