Dotrox

А каким образом вы передаёте туда информацию о посетителях? В смысле не просто факт посещения, а те данные, по которым Метрика сможет идентифицировать конкретного посетителя. Кстати, в Гуглоаналитике уже несколько лет есть бекенд аналитика для отправки данных с сервера, а не из браузера (просто факт для сравнения сервисов ). Ну, а в Директе то какой смысл? Если сайт ориентирован на украинскую аудиторию, Директ его потенциальная аудитория не увидит, потому что он не будет загружаться на сторонних сайтах, а на самом Яндексе он вместе с ним самими не будет загружаться. А вы вообще понимаете в чём суть блокировки? Если в Украине заблокирован доступ к Яндексу, каким образом с Яндекса может пойти трафик, если люди им больше не пользуются? И хостинг тут не при чём!

Покажите сайт. Дальше без ссылки гадать бессмысленно.

Это всё не имеет значения. Дело только в вашем провайдере, который заблокировал ВК. Этот код грузится браузером, а не сервером, а потому хостер на него никак не влияет. Стандартные варианты, где может быть этот код: шаблоны шапки и футера и поле в админке для вставки кода Гуглоаналитики.

А смысл? Метрика - это средство сбора статистики о посетителях сайта. Ваша аудитория находится в Украине, то есть для неё будет заблокирован доступ к Яндексу, а это означает, что Метрика не будет загружаться на страницу, когда пользователь будет открывать ваш сайт. Соответственно, смысл в использовании Метрики пропадает. Пользуйтесь Google Analytics.

А вы, наверное, читаете сообщения через строку: И реальный пример: как часто вам приходилось допиливать, например, Simple? Я синхронизацию с 1С всегда реализовывал вообще без сторонних модулей, на основе CSV файлов. И вообще, мой главный принцип: меньше модулей - меньше проблем. Если бы вы начали читать эту тему не с последней страницы, то узнали бы, что это сейчас самая популярная в мире е-коммерс платформа, которая обошла даже Magento. И, вероятно, глядя на этот успех, Дэниэль решил и своё подобие SaaS запилить. А вот кому сдался ваш cs-cart, который вы постоянно противопоставляете ОК - это действительно интересный вопрос.

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

Нет, конечно. Но и вы ведь не бесплатно работаете? Речь шла о том, что есть стоимость движка и стоимость доработок. В случае ОК стоимость движка - 0. В результате для ОК: 0 + стоимость доработок, для cs-cart: 25к + стоимость доработок. Даже у Shopify, который вообще SaaS, всё равно есть сообщество разработчиков, которые занимаются допилами магазинов на этой платформе. Ну, а в плане конкретно этого форума - это ж не просто магазин модулей, у форума есть своя сборка и она достаточна популярна в Рунете. Просто надо будет в неё впилить в дополнение к официальному репозиторию ещё и местный. Зато это будет довольно нехилый удар по варезникам маскирующимся под маркеты и продающим все модули по 100 рублей.

А можно пруф? Я слышал только заявление о том, что СБУ не будет применять какие-либо меры к приватным предприятиям использующим 1С. А по поводу блокировки - вот приложение к решению РНБО: http://www.president.gov.ua/storage/j-files-storage/00/40/30/6f76b8df9d0716da74bb4ae6a900d483_1494864914.pdf Пункты 275 и 276 - нехилый список ссылок на сервисы Яндекса, доступ к которым должен быть заблокирован. В пунктах выше есть ещё сайты Касперского и Доктора Веб. Пункт 422 и несколько последующих - блокировка ресурсов мейл.ру, в том числе ВК и ОК.

То есть, вы хотите сказать, что 25к за движок + стоимость ваших доработок - это всё равно дешевле, чем бесплатный ОК + стоимость ваших доработок? Я поддерживаю пачку магазинов и ни в одном нет модулей с ИонКубом (речь идёт о магазинах сделанных полностью мной, а не взятых на поддержку в готовом виде - в готовых всякое встречается), да и вообще сторонних модулей минимум, потому что 80% модулей в маркете - это шлак написанный школьниками и открытый код не спасает, когда нужно перепиливать модуль наполовину просто, чтоб сделать его работоспособным в реальных условиях (а не в магазине на два десятка товаров, где их тестируют автора). Более того, с выходом двойки я вообще прекратил делать магазины на ОК! Если 2.0 просто была непригодно для использования, то в случае с последующими версиями дело в том, что я принципиально не приемлю модификаторы. В случае vQmod я просто его никогда не ставил, но выпиливать OCMOD - это уже был бы перебор. Нужен в принципе другой подход! ИонКуб, как показывает практика, совсем не является защитой от варезного распространения модулей. И пофиг, что декодированные модули в 99% случаев работают криво - люди всё равно их ставят. Нужна прямая установка из централизованного репозитория с привязкой к аккаунту пользователя (и магазину). Отсутствие архива с кодом уже существенно сократит количество желающих им поделиться. Кстати, ИонКуб совсем не был бы проблемой, если б архитектура ОК не была такой дебильной и использовала мидлвары/декораторы/события. То есть, никаких правок исходников: нужно что-то поправить - подписываешся на нужное событие, делаешь правку данных (не кода) и всё. И с обновлениями тоже никаких проблем бы не было, как и с совместимостью.

Магазин на 5к товаров безо всяких модулей кеширования должен иметь TTFB не более 500мс даже на шареде! Иначе одно из двух: либо хостинг совсем шлак, либо в магазине есть конкретные проблемы, которые надо исправлять.

Вы читали/делали то, что в описании модуля в блоке "Работа с поддоменами"?

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

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

Почти. Нужно было ещё заменить точку в конце последней оставшейся на запятую.

Я попробовал попереключать города, телефоны иногда меняются. И у вас какая-то каша с самим переключением: например, переключаюсь с Екатеринбурга на Москву - поддомен Москвы, а переключатель показывает текущим городом Воронеж и телефон, видимо, соответствующий Воронежу. Мне кажется, что гео куки неправильна ставится. Она ставится сейчас отдельно на каждый поддомен, а надо бы сразу на все поддомены общую. Через что вы реализовывали эту георазбивку?

Замените эти две строки $this->language->get('entry_phone') . ": " . $this->request->post['phone'] . "\n" . $this->language->get('entry_comment') . ": " . $this->request->post['comment'] . "\n", На такую: $this->language->get('entry_phone') . ": " . $this->request->post['phone'] . "\n",

Покажите его код (скопируйте и вставьте в пост через кнопку вставки кода, а не весь файл вложением).

В более общем плане - редирект средствами веб-сервера (nginx/Apache) работает быстрее и с меньшим потреблением ресурсов, поскольку нет необходимости запускать процесс php и выполнять какой-либо код. Но конкретно в этом случае имеем просто кладезь того, как делать не надо: $_SERVER['HTTPS'] - может содержать какое угодно значение в зависимости от конкретного веб-сервера и его настроек, например, там может быть "off" и в результате такой редирект не сработает, потому что проверяется только наличие, но не значение индекса. $_SERVER['SCRIPT_URL'] - очень часто не существует, в результате всё будет редиректить на главную страницу.

Вы ожидаете здесь сочувствия или помощи? Видимо, сочувствия, иначе бы не поленились указать всю информацию.

Это довольно плохое решение сразу по многим причинам! Такое надо делать через редирект в .htaccess.

Да.

Если б вы открыли сетевую вкладку в инструментах разработчика браузера, то увидели бы, что при отправке формы в ответ приходит вот это:

Выше уже был дан ответ:

А при чём тут Твиг? И каких людей вам не достать? И какую вашу работу они добьют?

Роботы - это роботы, а фрод - это фрод. Фрод - это мошенничество. Данные покупателя из заказа проверяются через антифрод базы. В вашем случае проблема из-за того, что включён какой-то модуль антифрода, но, похоже, что самого файла модуля нет.