Dotrox

Ubuntu

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

В консоли браузера (инструменты разработчика).

Пример на предыдущей страницы. Подробнее здесь: http://php.net/manual/ru/function.sprintf.php А зачем они в вашем посте? Вы либо выкладывайте чистый php код, либо тогда уже весь модификатор, а не огрызки. Но лучше всё же чистый код. Тут оказывается уже изначально бред. Спросите у автора этого модуля, зачем он конкатенирует пустые строки перед и после $product_info['name']? В ОК только один тип файлов предназначен для того, чтоб в них писать тексты - это языковые файлы, которые лежат в /catalog/language/ и /admin/language/ (в директориях своих языков). Писать какие-либо тексты в других местах - это гавнокдерство!

А вы можете хотя бы сами себе объяснить как эта строка должна работать? Уберите все тексты в языковые файлы и используйте sprintf, может, тогда сможете отделить мух от котлет. И каково назначение квадратных скобок вокруг всего этого?

По скрину не похоже это на зависание, а просто именно на отсутствие перехода к следующему этапу. Что в это время пишет в консоли?

Да. Его, в принципе, не рекомендуется использовать Такого "счастья" в ОК очень много: например, сколько танцев с бубном нужно для нормальной работы https, хотя формально он https уже кучу лет поддерживает. Или стандартная нехватка индексов в базе, из-за которой из коробки ОК не потянет нормально больше тысячи товаров. Если хорошо разобраться, то окажется, что ОК на самом деле выходит не таким уж и дешёвым по сравнению с конкурентами, ибо поставляется в виде сырого замороженного полуфабриката, который в оригинальном виде пригоден только чтоб отравиться. По нормальному, js вообще должен использовать базовую ссылку по аналогии с тегом base у файлов и тогда не будет никакой путаницы с путями. Сам js ничего такого не предусматривает, но можно читать тот же base, например, и использовать для этих целей.

Долбите до тех пор, пока они вам не дадут ссылку на статью, где эти проблемы описаны (либо не перестанут отмазываться). Потому что на самом деле это бред: .htaccess обрабатывается до того, как запрос перейдёт к ОК, а значит проблема конкретно в .htaccess либо самом Apache. Покажите как у вас сейчас выглядит основной .htaccess и .htaccess в директории admin.

Именно это. В идеале - во всех контроллерах страниц. Минимум - главная, товар, категория, страница бренда, инфо страница.

А вы уверены, что у них это именно отдельные версии, а не адаптивная?

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

Я эту идею два дня пытаюсь донести Просто мне казалось, что она достаточно очевидна, чтоб не расписывать все нюансы.

Жизнь не ограничивается рамками сессии Смысл то как раз в том, чтоб писать в куки свой идентификатор и его же в базу. И тогда пофиг на сессию. При чём один механизм и для зарегистрированных и для незарегистрированных. Просто для зарегистрированных будет ещё дописываться id покупателя. И тогда вдобавок никаких проблем с привязкой к акаунту покупателя товаров просмотренных до входа/регистрации. Для магазинов идеальное решение - это гибридное приложение, то есть SPA, но с серверным рендером при входе (прямом запросе).

Тогда долбите поддержку.

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

Сидят Что у вас здесь за кавычки: ? Должны быть прямые, а вы скопировали с того сайта косые. А вообще у меня есть подозрение, что у вас .htaccess в админке вообще не обрабатывается, потому что он бы со всеми этими ошибками должен был выдавать ошибку 500. Или под страница недоступна вы подразумевали именно её?

Если вы посмотрите демо шаблона, то увидите, что там практически именно то, что вы и хотите. Так что ищите модуль всплывающей корзины и отключайте.

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

А если у товаров будут пятизначные id? Между количеством просмотренных товаров и размером куки, в принципе, не должно быть линейной зависимости! И, кстати, 2800 байт - это более 2,5Кб, что довольно много всего лишь для одного из заголовков. Как раз в вашем случае на это не стоит полагаться, ведь фишка вашего модуля в условно неограниченной истории просмотров, так что, думаю, многие будут ставить лимит больше сотни. Это в обычных модулях проблема решается фиксом в виде обрезки списка до лимита вывода (авторы почему-то ленятся сделать это самостоятельно), но там этот лимит обычно не превышает десятка, ибо для вывода в блоке нет смысла в большем. Сократите им время хранения (незарегистрированным, то есть). Либо вы сильно преувеличиваете, либо вы что-то перемудрили. И как быть, если в магазине половина посетителей зарегистрированные? Я, например, часто делаю вечный логин на основе авторизационной куки. Это значит, что после первого входа в определённом браузере пользователь там остаётся залогинен неограниченное время. По вашим словам получается, что из-за записи просмотренных в базу для такого большого количества посетителей должны появится ощутимые тормоза. Кстати, о каких пользователях идёт речь вот здесь (про логин): ? Если о покупателях, то вот это как раз может быть источником тормозов. При чём админ о них может так никогда и не узнать, а покупатели, возможно, вообще войти не смогут. Которая и так есть. Или вы думали о хранении в разных таблицах истории зарегистрированных и не зарегистрированных? Ну, и вообще, меня удивляет отношение к информации о просмотренных товарах, как к ненужному мусору, смысл которого только развлечь покупателя. А ведь это незаменимый маркетинговый инструмент.

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

Тем не менее, для og_image это всё же сделали правильно. Правда, там оно добавлено пулл реквестом. Но главное не это! Устанавливать ссылку через Document формируя в контроллерах через $this->url->link() или же выдирать из REQUEST_URI - это вопрос наполовину религиозный. Но вот обрезать слеш вначале ссылки через substr - это индикатор человека, который месяц назад познакомился с php (и до этого вообще программированием не занимался). Ну, а зачем там отдельно проверяется протокол и выбирается ссылка на домен, при том, что это уже сделано здесь же чуть выше - тут вообще без вариантов. Разве что таки сознательный саботаж. То есть, если оценивать оригинальный код целиком, то его писал либо ребёнок (если не по возрасту, то по уровню интеллекта), либо кто-то сознательно подлил дерьма в код ocStore. А вы можете описать те отличия из-за которых в моём варианте должны возникнуть проблемы, а в вашем их не будет? При условии, что у вас нет тегов (а также товаров или категорий) с названием ocstore, результат работы обоих вариантов будет одинаков. А разница почувствуется, когда длина REQUEST_URI хотя бы на символ изменится в пределах тех символов, которые должны обрезаться. Например, в начале не окажется слеша или там окажется лишний слеш, или сайт переедет в корень домена - substr будет либо оставлять лишнее, либо обрезать нужное.

Но учли только свистелки. Модуль, как и все остальные известные мне модули просмотренных, пишет все товары в куки (по крайней мере для незарегистрированных). Почему это плохо я уже описал выше. Кстати, а что будет, если я просмотрю несколько товаров, а потом зарегистрируюсь?

А чем вам мой вариант не нравится? Использование substr - это очень плохая идея, ибо он вслепую режет строку. Например, если вы захотите перенести сайт в корень домена, substr начнёт обрезать начальный кусок ссылки на страницу.

Вот потому и не можете понять Надо делать полностью по аналогии с og_image (и сеттер и геттер) и тогда моё решение вообще не нужно. А иначе нет смысла трогать Document - он нужен только для того, чтоб можно было из контроллера страницы в контроллер шапки передать какую-то информацию. То есть, правильное решение: добавляем в Document и сеттер и геттер и устанавливаем в контроллерах страниц (товар, категория и т.д.) ссылку через сеттер документа, а формируем ссылку для него через $this->url->link(). А затем в контроллере шапки получаем геттером установленную ссылку и передаём в $data['og_url']. Либо неправильное решение (но простое и быстрое): вообще не трогаем ни Document, ни контроллеры страниц, а просто используем код, который я привёл несколькими сообщениями ранее. Но только что-то одно из этих двух вариантов. Не надо пытаться их смешивать!

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