Dotrox

Есть причины, по которым вы не можете сделать просто вот так: $order .= '&filter_order_status_id=2'; ?

А действительно. Я про него как-то не подумал. Просто большинство модулеписателей под ОК о Гитхабе разве что слышали :)

Странный совет. Первое, что нужно делать для оптимизации сервера - это выкидывать Апач. nginx + php-fpm работает существенно быстрее, при этом потребляя меньше памяти!

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

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

Если у вас nginx слушает наружу, то он и отвечает за статику и любые правки в .htacces для статики будут просто бесполезны. И сжатие != кеширование. Про сжатие статики средствами веб-сервера никто не говорит! Ну, а для кеширования никакой разницы нет: какой сервер статику отдаёт, тот и отвечает за кеширование.

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

Это ответ не на тот вопрос, который я задал. А я задал вопрос: если вы сейчас зарегистрируетесь, вы увидите себя в списке покупателей или нет? Ну, и удалить файлы модуля мало, надо ещё кеш vQmod почистить.

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

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

Ищите какие модификаторы влазят в процесс регистрации. Возможно, вы что-то ставили для уменьшения количества полей при регистрации.

Тогда этот мод нельзя считать совместимым с двойкой. vQmod в двойке в принципе не нужен и категорически не рекомендован. А уж тем более, ставить его ради такой мелочи. Непонятно, почему вы не можете сделать отдельную версию модификатора под OCMOD?

У вас модуль перестал выводиться или не появляются в нём новодобавленные товары? Если товары не появляются, то вы просто не выбрали в админке лимит для вывода. Дефолтный лимит - 5 товаров.

Этот способ достаточно эффективный, если вы понятия не имеете откуда проблема и хотите решить её своими силами.

Удалите блок с id top. Это от него полоска и в нём нет никакого смысла сейчас.

Вам нарисовать скрин, где шапка в порядке? Какой совет вы ожидаете, если нет ссылки на сайт и, соответственно, не видно вашу вёрстку?

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

Видимо, мы о разном говорим. Я имел ввиду, что в $argv только ключ, который сразу проверяется и всё. А остальной код уже по потребностям и в том числе может и не сильно отличаться от обычного входного скрипта, если есть необходимость. Ну да, например, отправка почтовой рассылки - как раз пример работы через фронтенд. Когда в базе всего сотня покупателей - всё отлично, но когда их там тысячи - это превращается в полнейший маразм. Ну, и вообще, смысл крон задач как раз в том, чтоб они делались без какого-либо человеческого участия и фронтенд тут никак не клеится. Так в том и суть, что это магазин. В любом нормальном фреймворке это из коробки, а тут магазин и 10 лет движку, но до сих пор этого нет. Тут же вопрос не только в финансовых операциях. Можно, например, подменить адрес покупателя и получить чужой заказ (а после отправки заказа исправить обратно и концы в воду). Да и даже без таких изощрённых сценариев - просто возможность получения посторонними доступа к аккаунту покупателя - само по себе уже проблема, на которую нельзя закрывать глаза. Тем более, что на ОК делают не только классические магазины - например, для мультимерчанта это уже критическая проблема.

Ну, так я ж именно об этом :) Тут это аж слишком явно.

Зачем? Если там только ключ для защиты от внешних запросов, то его можно сразу проверить и всё.

Журнал ошибок пишется в обычный текстовый файл, который можно просмотреть и без админки. Но ошибки 500 туда не пишутся по дефолту. Смотрите журнал в панели управления хостингом, там должны быть эти ошибки. И почистите кеш vQmod/OCMOD (в зависимости от версии ОК). И да, это тоже можно сделать без админки. Зачем вы вообще ставите модули с таких странных сайтов?

Я делаю похожим образом, но без wget, а ключ читаю из $argv. Можно, кстати, ещё проверять, что php_sapi_name() содержит cli, но там есть нюансы с точным названием в разных окружениях.

В таких случаях есть универсальное решение проблемы - нарисовать вам скрин, где всё в порядке :) Вы не написали, какой модуль ставили, не дали никакой информации по записям в логах - на какую помощь вы рассчитываете?

Это какую-то страницу выводить через отдельный входной скрипт глупо, а как, например, быть с кроном? А на счёт уязвимостей: первое, что приходит в голову - полное отсутствие защиты от CSRF на стороне витрины (в админке - токены).

Это и есть ответ на вопрос - убейте Апач. Как для выделенного сервера под один сайт у вас вполне нормальное железо, если не нагружать его всяким хламом в виде Апача. Поставьте связку nginx + php-fpm и невооружённым глазом сможете увидеть разницу. Ну и, конечно, на сервере должен быть SSD.