Dotrox

Два нуля в номере ничего не меняют, это всё равно ветка 2.2, на которой ocStore не выходил. У вас в директории /catalog/controller/startup должен быть файл seo_pro.php. Сделайте его бекап, а затем замените содержимое на код отсюда: https://github.com/rb2/opencart-seopro/blob/oc2031/upload/catalog/controller/common/seo_pro.php И после этого замените в начале файла ControllerCommonSeoPro на ControllerStartupSeoPro.

А откуда у вас SeoPro? На версии 2.2 нет ocStore, где SeoPro из коробки. Значит у вас либо какая-то другая сборка, где что-то намудрили с SeoPro, либо вы SeoPro сами ставили и опять же, какую-то левую версию.

Вопрос не в панели, а именно в лицензии. У всех панель общая на все магазины, но при этом во многих шаблонах других авторов на поддоменах лицензия отваливается, потому и возник вопрос.

Проверьте, что у вас все языковые файлы перенеслись (а перенеслись, явно, не все).

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

Комплексного учебника не встречал. Все мои знания - это Гугл (исключительно на английском) и опыт. В ОК нет таких ссылок.

Вы абсолютно везде прописали https (не самый правильный способ, но достаточно эффективный)? Вот пусть проверят, что они вам настроили. Редирект на ссылку с адресом порта происходит за пределами доступными вам (судя по .htaccess), так что вы в любом случае это сами исправить не сможете.

Вообще-то, там сказано, что определения термина валидности взято из доков к 2.1 и только лишь об этом! Но сама валидация идёт по стандарту CSS3, что видно даже по параметру в ссылке. Но заглядывать в ссылку нет нужды, ибо о том, по какому стандарту идёт валидация написано прямо возле адреса страницы: Но меня больше смущает автоматическая активация. Не означает ли это, что при каждом открытии страницы магазина идёт запрос к серверу лицензий? И главный вопрос, который и вызвал интерес к вашему шаблону - мультимагазин. Из ваших ответов на последних двух страницах как-то всё получается очень расплывчато. Вроде, поддержка мультимагазина и есть, но с нюансами. Поэтому задам простой прямой вопрос (и хочу услышать такой же ответ): если сделать на вашем шаблоне мультимагазин с региональными поддоменами, будет ли всё в шаблоне работать так же корректно, как и в случае обычного магазина? И будет ли всё работать сразу из коробки без необходимости обращаться к вам за какими-либо дополнительными действиями (например, что-либо делать с ключём лицензии, чтоб она начала поддерживать поддомены)? Ответ хотелось бы увидеть в этой же теме, а не в личке. Думаю, он будет интересен многим.

Какая у вас версия?

Как ни странно, но информация в данном случае очень полезная. У вас редирект на https ведёт сюда (порт в ссылке): https://plombamarket.com.ua:443/ Отсюда и возникают проблемы с бесконечным редиректом, потому что потом ОК пытается его перенаправить на нормальную ссылку, а оно назад сюда. В .htaccess у вас редиректов на https нет, значит проблема в настройках хостинга. И, похоже, что в самом ОК вы тоже не всё настроили, потому что он пытается при исправлении ссылки перенаправить на http версию.

Нет! Можно только увеличить срок жизни сессии, чтоб не выкидывало так быстро.

Ни один из редиректов, которые вы привели, в принципе, работать не должен (как вы ожидаете). Если они изначально выглядели именно так (а не вы сами что-то там докрутили), то это не совет, а чья-то шутка. Эта "интересная команда" лежит в стандартном .htaccess ОК и, соответственно, на любом сайте с ним. Последние 4 строки отвечают за работу ЧПУ, перед ними строка, которая блокирует прямой доступ к загружаемым файлам, а перед ней 2 строки - это правила, которые перенаправляют стандартные ссылки сайтмапа и Гуглобазы на адреса модулей, которые отвечают за генерацию соответствующих файлов. А первая строка указывает, где лежит движок относительно корня домена, чтоб ссылки правильно формировались. Правильный редирект для перенаправления первой страницы пагинации на чистую ссылку - это довольно нетривиальная задача. Выглядеть он будет так: RewriteCond %{QUERY_STRING} ^(.*)&?page=1([^\d]*)$ RewriteRule ^/?(.*)$ /$1?%1%2 [R=301,L] Добавлять сразу после строки RewriteBase /

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

Кеш ОК почистить надо было. В вашем примере ссылка на товар, а не категорию. Если у этого товара не прописан SEO Url, то ЧПУ у него не будет ни в каком виде. Все редиректы надо добавлять не в конец, а сразу после RewriteBase / иначе результат может быть самым разнообразным (например, в ЧПУ ссылках появляется _route_, которого ни в каких быть не должно).

У меня в Мозилле все эти ошибки выводятся! И вообще, они от браузера не зависят (по крайней мере в данном случае ни одна из них с браузером не связана). А ошибок у вас там и без showcase полно. Для начала обновите кеш модификаторов.

Как и с любой новой технологией. А потом во всяких лайфхаках начнутся советы в стиле "ускорьте свой мобильный интернет в 10 раз" и решение в виде открывания только сайтов с молнией Не исключаю, что даже появятся плагины, которые будут отфильтровывать из выдачи не AMP сайты, чтоб не нужно было самостоятельно присматриваться. Учитывая, что AMP имеет реальную практическую пользу для пользователей в виде прироста скорости и экономии трафика (а не очередная SEO хитрость в игре с поисковиками), он всё же со временем укоренится и станет не меньшим де-фактом стандартом, чем в своё время адаптивность. Мне кажется, его пока просто рано внедрять с точки зрения технической готовности. А когда придёт время, вероятно, большинство шаблонов буду укомплектовываться AMP версией из коробки.

Я просто оставлю это здесь: https://www.ampproject.org/case-studies/greenweez/ https://www.ampproject.org/case-studies/wompmobile/ https://www.ampproject.org/case-studies/wego/ И обращаю внимание, что это всё примеры с сайта AMP, так что кто действительно интересуется темой, должен о них знать. Если я увидел в выдаче страницу интересующего меня товара, перешёл на неё и она открылась в 5 раз быстрее, чем страницы других сайтов, то какая мне разница сколько товаров в этом магазине? Ну, а дальше я просто буду в первую очередь переходить на те ссылки, которые помечены значком AMP, потому что знаю, что они открываются намного быстрее (а в добавок ещё и трафик экономят, который в мобильных сетях пока всё же лимитирован).

AMP даёт значёк, а он в свою очередь даёт ПФ (по крайней мере, когда пользователи заметят, что страницы с этим значком грузятся на порядок быстрее). Это всё не имеет смысла. Если пытаться делать адаптивную версию, как AMP, то таким сайтом на десктопе пользоваться будет нереально. Если сделать отдельную мобильную в стиле минимализма AMP, то в плане веса страницы, может, она и составит конкуренцию AMP, но вы забываете один существенный нюанс - AMP грузится из кеша Гугла, что даёт две важные особенности: это статическая страница (считайте, что это обычные html) и она грузится с серверов Гугла. Более того, все скрипты предоставлены Гуглом и также грузятся с его серверов, что означает, что оно всё будет закешировано в браузерах после первого посещения какой-либо AMP страницы любого сайта и процесс загрузки будет представлять из себя загрузку непосредственно тела страницы + изображений. И именно загрузку и всё, без какой-либо генерации, ибо это статичный html. В общем, если сильно постараться, можно приблизиться к AMP по скорости, но в результате получиться всё равно худшая скорость загрузки и отсутствие значка AMP в выдаче и при этом такая же кастрированная версия, а потому нет смысла изобретать велосипеды. Я не утверждаю, что AMP - это просто таки must have, но если уж двигаться в эту сторону, то таки AMP, а не "супермегатурбо" оптимизации. Но с ценой модуля действительно немного перебор.

У вас ещё и Journal. Прежде всего уберите везде из конфигов www (судя по тегу base, вы точно где-то www не убрали) и проверьте, что в настройках шаблона домен тоже нигде с www не вписан, потому что у вас сейчас ссылки на все стили и скрипты с www. Правда, по-нормальному, в этих ссылках вообще домена быть не должно, но, видимо, это особенности Journal. Этот иконочный шрифт грузится с вашего сервера и в стилях у него прописан относительный путь, так что используется тег base для полного пути, а у вас в теге base чужой домен (www - считается отдельным поддоменом). Для загрузки шрифтов с чужого домена должны быть на этом домене разрешены кросдоменные запросы, чего у вас, конечно, нет. В общем, если вы избавитесь везде от www - проблем больше не будет.

Я же дал полный код редиректов. Это не постраничный редирект, а шаблонный. Постраничный редирект нужен, когда вам нужно какую-то одну конкретную страницу перенаправить на какую-то другую конкретную страницу. И начальная/конечная ссылки не имеют ничего общего - вот тогда и делается постраничный, потому что больше вариантов нет. А когда вам нужно абсолютно все страницы сайта перенаправить что-то меняя в ссылке (протокол, добавлять/удалять www), тогда делается шаблонный редирект, который работает сразу для всех страниц и его я уже написал в предыдущем сообщении вместе с редиректом на https, который, как я понимаю, уже у вас есть. Покажите сайт.

Последняя версия это 3.0.2.0 и там этого контроллера и не должно быть. А судя по номеру строки, в которой возникает ошибка вы скачали либо не последнюю версию, либо не с официального сайта, потому что в последней версии с официального сайта на этой строке комментарий. Какой полный номер версии у вас и откуда конкретно вы её качали?

Что-то вы всё же не так сделали. Вы какую версию ставили? Этот контроллер появился только в 2.3. Если у вас 2.3, то вы значит просто не все файлы на сервер залили. Не хватает файла /catalog/controller/event/compatibility.php. А в 3.0 этого контроллера опять уже нет.

В конфиге, видимо, у вас ссылка прописана с www, из-за чего отвалились стили. А в ссылке на иконочный шрифт, возможно, ещё и неправильный протокол, если она абсолютная. Исправьте домен в конфиге. Его в принципе делать нужно. У сайта должен быть один вариант, а не как ввели, так и открылось. Полностью это будет выглядеть так: RewriteCond %{HTTP_HOST} ^www\.(.*)$ [NC] RewriteRule ^(.*)$ https://%1/$1 [R=301,L] RewriteCond %{HTTPS} off RewriteCond %{HTTP:X-Forwarded-Proto} !https RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301] И не забывайте, что редиректы должны быть сразу после: RewriteBase / А ещё не забудьте конфиги ОК поправить.

Поставьте 444 и тогда это действительно станет интересным вопросом, а 644 позволяют записывать владельцу.

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