Yoda

Вас спасет только переезд на VPS.

КЭП!

Буквально вчера сталкивался с такой же проблемой. Таки да - это сео про, и как "полечить" слету пока не придумал.

Логи... Почему они вылетают как вы говорите?

Удивительное рядом... А если заглянуть в консоль бразуера можно увидеть много ошибок.

Модуль simple не при чем. Если письма не ходят - они не ходят! https://www.mail-tester.com/ Сделайте тестовую регистрацию на мыло с этого сервиса, и после покажите результаты.

Поменяйте местами конструкции. Сначала сделайте редирект на https После этого www-зеркало И потом уже системный роут для опенкарта.

Ну откуда же вы лезете. Неграмотные некультурные мамкины спициализды. Тыкайте пожалуйста себе в мягкие места. Я вам не друг, не мамка. Для тех кто в танке... Неуникальный, он же мусорный контент, а тем более ворованный, а тем более ворованный у яндекс маркета - это контент-труп. Он никогда не проиндексируется и на сотую позицию. Сказки рассказывайте вашим потенциальным клиентам. И по факту парсинг = воровство! Если вы со мной каким то образом не согласны, или имеет свою точку зрения изложите ее в виде жалобы спортлото!

Да не. Не в анекдоты. Ну не могут быть все умные и красивые. Людям на репутацию и на клиентов в массе вобщем то с большой колокольни жиденьким. Основная модель бизнеса студий и фрилансеров. Урвал 300-500 долларов, движок поставил, шаблон натянул, ворованных модулей наставил - нате вам магазин чпокайтесь. Другое дело, что 99% этих магазинов в нынешних реалиях обречены на провал. Но это никого не волнует. Зато студия же заработала. Куда далеко ходить. Посмотрите на концепцию работы недосео. Идей наворовали. Модулей наклонировали. Клиентов наразводили и рассчесывают. А как у кого бизнес в итоге - никого не волнует. Лишь бы заносили бабло. По моим личным ощущениям, большинство магазиносоздателей превращаются в менеджеров канадских оптовых компаний и адептов бизнес-молодости. Слава богу что есть его величество рынок, который не прощает подобные финты ушами.

Вы работаете по донорам-чертям. Которым наплевать на то что их парсят. Ну и в принципе, парсинг - это чертизм. Можно. Но сколько вы потратили вашего времени? Сколько стоит ваше время? А какой толк будет от этого контента? - нулевой. Краденый контент не стоит ничего потому что он очень плохо индексируется. Заплатите коприайтерам - это будет паритетно в деньгах потраченому времени и будет несоизмеримый эффект! Никак. Только общие правила и эвристика.

При желании... Карту сайта можно отдать только ботам.. И только ботам! Также у парсера есть признаки. Которых нет у людей. По ним очень легко определить и CD и шмеде и все что угодно. Прокси и соксы - я уже выше написал банятся на раз два.. В итоге все сведется к 5-6 используемым айпи, которые в черный список добавить за неделю - дело техники.

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

Да нууу... на самом деле же все просто. Та же методология что и с ддосом. Просто паттерны блокировок немного другие, и то! В случае если умные парсерщики. Но как правило даже на соксы никто не тратится и таймауты не добавляют. Так что если вдруг один айпи за десять минут посмотрел 100 уникальных страниц, без единого повтора. Иди сюда мой маленький в баньку. Ну а всех секретов раскрывать не буду, дабы парсерщикам неповадно было.

OCMOD Отменили? И да как у вас там с поддержкой? Опять будете теряться на полгода и кидать заказчиков?

Не катит это поиск с учетом триграмм и левенштейна исправляет далеко не все. Инфиксы - тоже не супервариант. Словарь исправлений - долго и дорого. В целом надо делать все вместе.

И как будет это у вас работать, если где то в теле будет скрипт без jquery.ready? Как можно быть уверенным в корректной последовательности выполнения скриптов в дополнениях, если у вас асинк и нет предварительных обработчиков событий? Как это пролезет с дополнениями, которые динамически подгружают контент с интегрированными скриптами? Сколько заказов потеряют клиенты с косяком при оформлении заказа при подобном механизме? Какие 100 из 100 оценок pageSpeed на который влияет еще вагон и маленькая тележка ресурсов, кроме js есть css ttfb и иже с ними.. НУ бред же .. И развод на бабки хомяков.

Опять форум превращается из базы знаний в рекламную площадку кривой конторы.

Меня такие мысли не покидают уже неделю!

Тугосери атакуют! Очень напомнило:

В таком формате он там сравнительно недавно. По хорошему. Так как в Mega фильтре коллекция значения атрибутов кешируется и кешируется грамотно с возможностью выставить произвольное время хранения а не час по дефолту, для среднестатистического проекта, в котором до 500 товаров на категорию, особой оптимизации этого запроса не нужно. Да и опять же, как его оптимизировать то? Если у нас там тип поля text. Также эта конструкция совершенно по иному воспринимается, если вспомнить, что в фильтре есть возможность сегментации значений при помощи разделителя, например: цвет: красный, зеленый - могут быть уникальными значениями красный (3), зеленый (5). В таком формате в принципе про любые индексы можно забыть. Как альтернатива авторы Mega фильтра предлагают версию PLUS, которая создает уникальный индекс в дополнительные поля в таблицу product. Но у меня ни разу не получилось увидеть выгоды от использования PLUS, так как просто кастомная оптимизация вышеприведенного запроса дает лучшие результаты. Формировать отдельный индексируемый справочник с crc32('text') значениями, авторы фильтра я так понимаю считают излишней роскошью. Поэтому на больших проектах способы борьбы достаточно простые - вырезать все лишнее, немного перестроить порядок полей в запросе, немного составных индексов ну и правильно сконфигурированный mysql сервер - до 10к товаров, практически панацея. А вот на примере 75-100 к товаров на категорию с десятком значений атрибутов, это уже не вариант, но здесь на помощь приходит sphinx и json поля.

А не засланный казачок ли ты Вася, часом? То тебе понять и простить варезятников. Теперь докажи авторство... Фото МПХ не хочешь потребовать в свидетельство?

Это логика неудачника. Представьте, вы торгуете апельсинами на рынке... У вас цыгане воруют апельсины и бегут, вы бежите за ними, их ловите. А они такие: ой, мы не знали они же просто лежали там на столике. Купит надо, да, конечно дорогой будет счастье тебе, удача, куплю, на тебе деньги, скажи спасибо что купили. А ты им такой: да да дорогие канешна канешна, за купите, вот правую руку отрублю вам... и покупайте.

Стучать - не стучать дело личное и каждого. Но закрытый от посторонних глаз реестр варезомагазинов напрашивается давно. Но откровенно говоря, сугубо из моей практики, очень дорого помоечка аукивается владельцам магазинов. Хочешь не хочешь в среднем владелец магазина вкладывает $500-2000 в разработку магазина. Просадка из-за ботнет атаки аукивается выпадением из индекса и в 90% случаев отсутствием возможности вычистить проект самостоятельно. Так что господа любители халявы по сути рубят сами сук на котором сидят. Но у меня больше вопрос о другом - насколько этично всаживать в дополнения шеллы, либо раскладывать какие-либо закладки на момент работ? По факту это огромное зло и неуважение к заказчику в принципе. Если не платят 100% предоплаты - никто не мешает работать на собственном окружении на копии проекта. А ситуаций когда не дам доступы... только у меня... начальник так сказал... и так далее. Ну их не так уж и много встречается.

Да что вы говорите. Т.е. мануал по mysql вы не читали, но про свойства класса знаете. Давайте все таки тогда начинать сначала. Что более приемлемо? Работать с готовым набором данных, который может быть использован при повторных инициализациях? Или только в рамках одной как свойства класса? И еще не все же такие талантливые, и не все могут настроить тот же мемкеш. Так вот в рамках одной иницализации кешрование с свойства класа подобных данных нецелесообразно, а кешировать массу атомарного хлама в системный кеш движка - это на зло папе отморозить уши.

Почитайте мануал по mysql, ничего что она сама по себе кеширует подобные запросы? И ничего что если кешировать подобные запросы на достаточно большом объеме, файлы в папке с кешем убьют в хлам производительность всей системы?