Dotrox

Ищите другие модули как-либо связанные со страницей товара и записывающие что-либо в куки или локальное хранилище.

Ну, так это уже совсем другая проблема! Замочка нет потому, что у вас остались на странице какие-то ссылки без https. Эти ссылки либо вставлены вручную (например, ссылки в баннерах), либо у вас есть какие-то очень кривые модули.

И это я тоже уже написал:

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

При чём тут вообще относительные ссылки? Там надо поменять http на https!

Обычные конфиги (config.php) в корне сайта и в директории admin.

После внесения любых правок надо обновлять кеш окмод!

Здесь есть вариант решения, но оно ещё зависит от вашей версии модуля (вроде, помогает не всегда) - Видимо, говорит, что руки у него (автора) растут из мест, которыми сложно писать код, а потому пользуйтесь, как есть Об этом модуле на форуме уже много написано "хорошего", он часть какого-то шаблона и у всех с ним проблемы.

Вероятно, вы удалили единственный товар, который там выводился. Где модуль находится зависит от вашей версии ОК, но независимо от версии он находится там же, где и остальные модули. Например, для ocStore 2.3 - это будет Дополнения -> Дополнения -> опция Модули в фильтре вверху страницы (обычно оно выбрано изначально). А называется он "Рекомендуемые", если речь идёт про стандартный модуль, а не какой-нибудь от шаблона. Для заполнения товарами просто выбираете в нём (добавляете) какие товары хотите выводить. А на главной он должен сам появится после добавления товаров, если он там уже был изначально.

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

По тексту же видно, что это какая-то защита от ботов. Так что это точно к хостеру!

Смотрите журнал ошибок или просто на сетевой вкладке инструментов разработчика посмотрите на начало тела ответа сервера. Похоже, что у вас там ошибки выпадают, из-за чего браузер не может нормально страницу обработать. Быстрое решение - это отключить вывод ошибок, но надо всё равно разбираться, что там за ошибки.

Выберите в первом пункте SMTP и вбейте правильные данные для вашего ящика [email protected]. А второй откуда тогда? С DKIM для начала разберитесь. Судя по тому, что о приватных ключах вы не знаете, почта с сервера у вас таки не подписывается.

Вполне может быть. Только странно тогда, что всплыло именно сейчас.

Потому что письма о регистрации и заказе идут с сервера магазина, а письма с ящика идут с сервера Яндекса. А откуда они ещё могли бы отправляться? Точнее, они могли бы отправляться и с любого другого сервера, который бы вы сами настроили в админке прописав там данные для SMTP, но вы бы тогда об этом знали. Подумайте ещё раз, о чём вы говорите. Смысл приватных ключей именно в том, чтоб быть приватными, их никто кроме вас (вашего софта) знать не должен. То есть, в DNS их быть не может! Эти вопросы надо задать тому, кто вам прописывал публичные ключи в DNS. Публичные ключи не берутся из воздуха, они должны были быть сгенерированы на основе приватных.

У вас здесь запятая пропущена. Вероятно, следует сказать спасибо какому-то кривому модификатору.

Всё правильно. Там же префиксы разные. Если у вас письма подписываются и на сервере и на Яндексе, то в каждом случае свой ключ и он должен быть прописан в DNS со своим префиксом. Ну а правильность содержимого - это уже вопрос к тому, кто вписывал. Кстати, если у вас письма не подписываются, а DKIM прописан - это тоже может повлиять на попадание в спам.

Какая ожидаемая реакция от одного из авторов конкурирующей сборки Вы, кстати, обратили внимание, что 2/3 ваших сообщений на этом форуме направлены исключительно на разжигание флейма? Уж не саботаж ли это (тем более, что и форум у вас тоже есть)?

Такого никогда не будет Для этого и есть ocStore. Но да, я согласен, что пока состояние тройки ещё не пригодно даже в качестве базы для допила. Только факта неопределённости ожиданий это не меняет.

И было плохо и стало не лучше. Вот идеальный вариант: v=spf1 +a +mx include:_spf.yandex.net ~all Явно ip не нужно указывать, ибо "a" означает брать ip из А записей домена. А плюсы указывают, что при совпадении надо точно доверять, без них будет нейтральное отношение. У вас разве VDS? А если не VDS, то на вашем ip может быть ещё сотня пользователей, которые могут там хоть рассылать спам с призывами вступить в ИДИЛ! Но даже в случае VDS ip то кому-то принадлежал до вас и опять та же история. В случае с CBL, информация должна обновляться раз в месяц. И сам список содержит не спамные ip, а проблемные (открытые прокси, ботнеты и т.д.). Если через месяц ip всё ещё будет в списке, требуйте от хостера переноса на другой сервер, если у вас шаред или просто смену ip, если VDS. Но я не думаю, что наличие ip в этом списке является решающим фактором в вашем случае.

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

На примере osCommerce можно увидеть, что дерьмо в конечном счёте отмирает сколько б школоты вокруг него не летало! Что есть, то и нашли. Для тройки ocStore пока нет и непонятно когда будет.

Это не имеет абсолютно никакого значения! Главная причина, по которой письма попадают в спам - это адрес отправителя. В случае адресов на собственном домене - отсутствие или неправильный spf. Если у вас ПДД от Яндекса, скорее всего вы взяли дефолтный вариант "v=spf1 redirect=_spf.yandex.net", а должно быть "v=spf1 +a +mx include:_spf.yandex.net ~all".

Тут дело уже не во фреймворках, а в самих движках. Есть очень старая картинка, которая отлично описывает ситуацию с Мадженто: В ПрестаШоп всё не настолько запутанно. Как показывает пример Laravel, дело не столько в Symfony, сколько в умении его готовить. Правда, ПрестаШоп использует намного больше компонентов, чем Laravel, но говорят и Symfony 4 стал существенно быстрее предшественников. В общем, посмотрим. Нельзя их сравнивать! ПрестаШоп существенно сложнее, существенно прожорливее, но и существенно богаче по коробочному функционалу. Вдобавок, код там значительно более профессиональный. ПрестаШоп по этим параметрам можно сравнивать с Мадженто, но никак не с ОК. Но среди этой тройки он всё же между ОК и Мадженто. Хотя, конечно, ближе к Мадженто. Это и сейчас слишком разные движки рассчитанные на разные рынки (ПрестаШоп рассчитан на Западную Европу). И даже сейчас сравнение ОК с ПрестаШопом то же самое, что сравнение ОК с Мадженто!

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