Dotrox

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

Они начисляются в момент добавления заказа, если было за что начислять. При изменении статуса на завершённый только ваучеры отсылаются.

Не могу понять, зачем вы подключили реестр и лоадер, если они у вас не используются (реестр используется только для лоадера, который ни для чего). Но они таки вам понадобятся. $registry->get('load')->model('sale/order'); $registry->get('model_sale_order')->addOrderHistory(); А вообще, я бы это оформил в нормальный контроллер и вызывал из отдельной копии index.php.

Это не движок - это сторонняя js библиотека. При чём даже не сама она, а файл с примером использования, который был в комплекте с ней. Включите мозги - это библиотека для построений графиков и что удивительного, что в папке examples у неё пример графика, пусть и странной тематики. Вот этот файл на Гитхабе самой библиотеки - https://github.com/flot/flot/blob/master/examples/series-toggle/index.html И вот демо с тем же графиком - http://www.flotcharts.org/flot/examples/series-toggle/index.html А вот результат проверки файла с Гитхаба - https://www.virustotal.com/en/url/46c57e09600d5f2ed838f345b470549f1452f6ee53a8375b74732ced924dc707/analysis/1502139261/ Можете там же проверить свой, не думаю, что результат будет отличаться. Десктопные антивирусы малопригодны для поиска вирусов на сайтах.

Ну, прежде всего, его единственные лимиты - это лимиты непосредственно php. Кроме того, с ними обычно всё не так жёстко: например, max_execution_time для cli по дефолту 0, что означает отсутствие таймаута. И, как показывает практика, далеко не каждый хостер с этим что-то делает. Не уникальный, а просто достаточно красноречивый. Ещё можно привести примеры различных генераций. Например, генерация выгрузки для Я.Маркет довольно часто упирается в таймауты, если товаров много. То есть, оно в браузере просто перестаёт открываться и задача крона как раз решить эту проблему, а с wget ничего он не решит, а получит тот же результат (отсутствие результата).

Вот этого момента я всё никак не могу понять - что ты такое запускаешь через cli, что там нет доступа к валюте, языку и всему остальному? Как я уже писал выше, я для cli использую немного модифицированный index.php (в тех версиях, где он был толстым) и в результате имею доступ абсолютно ко всему, что доступно при обычном заходе на сайт через браузер (конечно, помимо данных, которые передаёт сам браузер). Мой вариант тоже так можно запустить. Правда. я обычно добавляю проверку на тип окружения, чтоб как раз из браузера никто не запускал. Но при необходимости можно проверку закомментировать и запустить. Но там могут быть разные задачи. Например, почтовая рассылка, которая вполне может длиться час. Если запускать такое через wget, то и в таймауты упрётся, и воркер Apache или php-fpm всё это время будет забит. На ukraine.com.ua, например, дают 10 воркеров Apache на весь аккаунт (а не на отдельный сайт).

Какой-нибудь модуль, например, фильтр или аякс навигация. Что-то конкретнее подсказать невозможно не видя сайт!

Нигде! ОК динамический движок и не хранит никакие данные в html. За исключением языковых файлов, всё в базе. Не можете найти, потому что её там нет. И ищите совсем не там. Вы модуль GeoIP сами настраивали? Если сами, то должны были бы помнить, что вписывали домен в его настройках в админке. Вот в админке модуля и исправьте.

Не только Апача (и не всегда именно его), а толще на весь веб стек (который несёт кучу ограничений и узких мест)! И там не было "потому что", там был просто список из различных недостатков такого метода, чтоб непосвящённым было понятно, чем этот вариант хуже. Люди, умеющие отправлять POST данные через wget, думаю, достаточно продвинуты, чтоб фильтровать информацию с форумов и понимать, когда им действительно необходим wget, а когда он не будет иметь никаких преимуществ перед cli, а только лишь недостатки. А люди задающие вопросы на этом форуме умудряются даже копипастя готовые редиректы зачем-то вносить в них правки, которые приводят к смешным результатам. И давая советы я пытаюсь это учитывать. Странно, что вы увидели в списке недостатков только ресурсы Список содержал все недостатки, которые пришли в голову, чтоб картина была более полной и информативной, но реально самый ощутимый недостаток, на который натыкаются люди довольно часто - это таки лимиты (различные таймауты, лимиты памяти, воркеров и т.д.), от nginx и до php включая всё, что между ними. И с этим глупо было бы спорить. Но смысл это имеет только для тех, кто вообще понимает разницу между wget и cli, а не просто использует то, что первым нагуглилось. А кто понимает разницу, и без меня хорошо знает обо всех недостатках запуска через wget.

Это не решение, а заплатка ломающая аякс навигацию. Решение на предыдущей странице.

Я всё же не понимаю о каких ресурсах идёт речь, которые доступны только через wget. Я, например, для запуска по крону использовал всегда модифицированную версию index.php и никогда при запуске через cli не чувствовал нехватки чего-либо. А относится к любому варианту запуска через tcp. В этом стеке куча лимитов, в том числе и объективных (например, количество портов), не говоря уж про всякие таймауты. А ещё можно посоветовать не печатать на клавиатуре пальцами, ибо от этого стираются надписи на клавишах. И это будет такой же глупый пример, как и с админкой - админка предназначена для браузера и других вариантов работы с ней и нет, а крон скрипт для браузера никак не предназначен. И то, что его можно запускать таким образом не значит, что нужно. Помимо того, о чём я уже написал выше, есть и другие особенности wget/curl: например, при переезде на другой хостинг можно забыть отключить на старом крон и до тех пор, пока там не закончится оплаченный период wget будет дёргать скрипт на новом, что будет приводить к двойным запускам и долгим попыткам найти причину. На моём опыте был более смешной пример: в магазине внезапно отвалилась автовыгрузка, которая запускалась кроном и заказчик уверял, что ничего не трогал уже давно. Как оказалось, за пол года до того был переезд и на новом хостинге на крон ничего не ставили, а выгрузку дёргал wget со старого хостинга пока, вероятно, там оплата не истекла. В результате получилась часовая бомба. Конечно, cli бы не спас от забывчивости заказчика, но выгрузка отвалившаяся сразу после переезда, а не через пол года - существенно упростила бы поиск причины. Да и вообще, делать доступными крон скрипты из браузера - это плохая идея. Особенно в случае модулей, когда путь известен и кто-то может захотеть побаловаться. Собственно, я уже привёл различного рода аргументы, почему wget/curl - зло по сравнению с cli, но так и не услышал ни одного аргумента против cli или в пользу wget/curl (про ресурсы я пока понять не могу, поскольку при cli запуске ещё не сталкивался с отсутствием чего либо).

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

Никогда не запускайте локальные скрипты через wget! Таким образом вы используете лишние ресурсы, создаёте лишнюю задержку, упираетесь во все лимиты, которые используются для запросов через браузер. Что у вас внутри update.php?

Ну, если очень надо, то можно его просто скачать и открыть локально. Но моя мысль была в том, чтоб просто не допускать таких логов. Никто и не говорил о чужих ошибках. Речь шла как раз о том, чтоб владельцы магазинов напрягались ошибками, а не просто отключали запись в лог и думали, что всё прекрасно.

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

Сеошники всегда пихают в аудит несуществующие ссылки, которых нет на сайте. Во-первых, место неправильное - в конец файла ничего добавлять нельзя, все редиректы должны быть сразу после строки: RewriteBase / Иначе в зависимости от стечения обстоятельств редирект или просто не будет работать или будет работать совсем не так, как вы ожидаете и вызывать лишние проблемы. И это справедливо не только для ОК, но и для других движков с ЧПУ: редиректы должны быть до директив, отвечающих за работу ЧПУ. А во-вторых, вы эту строку адаптировали под свой случай?

Сейчас не вижу никаких проблем, но судя по тексту ошибки, у вас там что-то лишнее выводилось перед самим сайтмапом, вероятно, какие-то ошибки php. Только там немного неправильно и, вероятно, сломает мультимагазины (если надумаете делать). Если у вас версия 2.2, то в этом месте уже должен был быть вот такой код: if (!$query->num_rows) { $this->config->set('config_url', HTTP_SERVER); } Нужно было вписывать указанную там строку в тело этого условия, то есть, должно было получиться так: if (!$query->num_rows) { $this->config->set('config_url', HTTP_SERVER); $this->config->set('config_ssl', HTTPS_SERVER); }

При открытии чего? При беглом просмотре я не смог увидеть у вас на странице таких ссылок. То, что они не выдают 404, не значит, что для них нужно ставить редиректы! В ОК можно придумать довольно много бредовых ссылок вручную и все они будут открываться. Редиректить нужно только те ссылки, которые где-либо могут найти поисковики. Кстати, у вас ссылка на страницу контактов в меню без https.

Почему вы для админки не прописали везде https? Не просто беда, а огромнейшая! Вы пробовали включать мозги когда копипастили найденное в интернете? Такое впечатление, что вы даже не пытались прочитать, что копипастите! Пойдём по порядку. Самое безобидное: # www -> ssl non www RewriteCond %{HTTP_HOST} ^www\.(.*)$ [NC] RewriteRule ^(.*)$ http://%1/$1 [R=301,L] Тут всё было бы идеально, если б не 2 нюанса: 1. у вас https, а здесь редирект на http, 2. в комментарии (первая строка) указано, что это редирект на ssl версию без www, а ssl = https (в данном контексте). То есть, редирект и несовсем правильный и комментарию не соответствует. Следующее уже веселее: # non ssl -> ssl RewriteCond %{HTTPS} off RewriteCond %{HTTP_HOST} ^(www\.)?(mysitename\.ru) RewriteRule ^ https://%2%{REQUEST_URI} Как вы думаете, что такое "mysitename\.ru"? Мне кажется, не нужно быть специалистом по .htaccess, чтоб догадаться, что здесь нужно было вписать имя вашего домена. Теперь переходим к тому, что вы скопипастили в конец файла. Прежде всего, если вы на этом форуме попытались бы найти информацию про редиректы для https, то в каждой теме по несколько раз прочитали бы, что все редиректы должны идти сразу после RewriteBase / Мне приходится это повторять снова и снова, а люди снова и снова пихают всё куда вздумается, а потом жалуются на проблемы. Теперь смотрим на вот этот блок: RewriteEngine On RewriteCond %{HTTP_HOST} ^www\.artmassa\.com$ [NC] RewriteCond %{REQUEST_URI} !^/robots.* RewriteRule ^(.*)$ https://artmassa.com/$1 [R=301,L] Зачем тут "RewriteEngine On"? Эта директива уже есть в файле и одного раза вполне достаточно (это к вопросу о слепом копипасте). Теперь смотрим на следующие строки - это редирект с www на версию без www. При чём редирект правильный (при условии, что здесь именно ваш домен, а не опять слепой копипаст), но зачем вы это добавили, если у вас уже и так есть в файле попытка такого редиректа? Да, тот редирект у вас не работает. Ну так удалили бы и добавили этот, а не пихали один за другим пока что-нибудь таки не заработает. В общем, удалите всё из вашего .htaccess и впишите это: Options +FollowSymlinks # Prevent Directoy listing Options -Indexes # Prevent Direct Access to files <FilesMatch "\.(tpl|ini|log)"> Order deny,allow Deny from all </FilesMatch> # SEO URL Settings RewriteEngine On RewriteBase / # www -> ssl non www RewriteCond %{HTTP_HOST} ^www\.(.*)$ [NC] RewriteRule ^(.*)$ https://%1/$1 [R=301,L] # non ssl -> ssl RewriteCond %{HTTPS} off RewriteCond %{HTTP:X-Forwarded-Proto} !https RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301] RewriteCond %{REQUEST_FILENAME} !-d RewriteCond %{QUERY_STRING} ^(.+)/$ RewriteRule ^(.*)/$ /$1/?%1 [R=301,L] RewriteRule ^sitemap.xml$ index.php?route=feed/google_sitemap [L] RewriteRule ^googlebase.xml$ index.php?route=feed/google_base [L] RewriteRule ^download/(.*) /index.php?route=error/not_found [L] RewriteCond %{REQUEST_FILENAME} !-f RewriteCond %{REQUEST_FILENAME} !-d RewriteCond %{REQUEST_URI} !.*\.(ico|gif|jpg|jpeg|png|js|css) RewriteRule ^([^?]*) index.php?_route_=$1 [L,QSA] Большая часть этого кода у вас уже есть. Я просто убрал лишнее и подправил ошибки. И в конфиге админки пропишите везде https.

Там всё сложнее. Дело не в хостерах, а в ОС и панелях. Например, у Debian есть собственный скрипт очистки сессий, который висит на кроне, у ISPManager, насколько я помню, тоже есть собственный. Ну, и таки некоторые хостеры действительно ещё и свой добавляют. В конечном счёте получается, что в 2/3 случаев файлы сессий удаляет не php, а эти скрипты и потому от настроек нет толку.

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

Это изначально такой был или после ваших правок? В любом случае, попробуйте тогда отсюда: https://github.com/myopencart/ocStore/blob/ocStore2/upload/catalog/controller/startup/seo_pro.php В этом ничего править не надо, просто скопировать код.

Тогда обновите кеш модификаторов. Если не поможет, то ищите файл /system/storage/modification/catalog/controller/startup/seo_pro.php и выкладывайте его сюда.

Вы включили назад SeoPro в админке?