В robots.txt запрещаете индексирование Disallow: /*&showall_1= и /*?showall_1=. В header ставите <link href="https:// ваш_домен.ру/ваш_адрес_страницы" rel="canonical" />, тогда пусть хоть 1000 одних и тех же страниц с разными параметрами, поисковики будут индексировать только нужные версии. Ну и совсем уж хардовый варианты - для "лишних" страниц ставьте в header <meta name="robots" content="noindex, nofollow" /> Все изменения в header придется писать самостоятельно - нет штатных механизмов.
Посмотрел со своих компьютеров - все нормально. Еще можно попробовать заархивировать сайт, скачать на свою машину, развернуть его и поиском попробовать найти, где этот телефон сидит (если уверены, что это скрипт). Конечно, если это какой то хитрый скрипт, то поиском не найдете. Но, скорее всего, это просто ошибка - разработчики оставили какой то старую/отладочную информацию.
Это не битрикс. Какой то плагин в хроме на том компьютере стоит или вирусы. Проверяйте, чистите этот особый компьютер. Попробуйте adwcleaner запустить - почистит немного с последующей перезагрузкой.
Алексей Пустоутов, не слушайте ни кого, делайте, да воздастся вам благодарными пользователями! Уверен, спустя какое то время Docker-контейнеры будут уже стандартным дистрибутивом Битркса
Только нагрузку создают, возможно, еще, парсят ваш сайт. Смотрите логи доступа access.log. Выбирайте ботов и баньте их в своем .htaccess. Например: # hacker deny from 95.30.30.13 # Hetzner - подсетка deny from 95.216.0.0/15
Или # баним бота по части user-agent RewriteCond %{HTTP_USER_AGENT} MJ12bot [NC,OR] # баним бот по рефереру (реф-спам). Обратите внимение на последнее условие [NC] - оно последнее, перед действием, поэтому не [NC,OR] RewriteCond %{HTTP_REFERER} ^http://.*darodar\.com/ [NC]
RewriteRule ^.* - [F,L]
После этого такие посетители будут видеть 403 ошибку. Только не забаньте ботов Яндекса и гугла
В реальности проблем будет куча, даже если все рекомендации Bitrix выполнялись. Например, у меня, при обновлении с 12.5 на 16 правильно не обновился двиг, в админке пропала куча функций (большое количество служебных *.js не обновилось автоматически). Лечилось копированием всех служебных директорий Битрикса из текущего дистрибутива, затем проверки, исправления БД штатными средствами. Так что нужно готовиться к проблемам. Лучше всего, обновить свой отладочный сервер, затем после всех исправлений выложить на рабочий.
Чем же вам не понравился TimeWeb? Вы просто не умеете его готовить: под большую нагрузку берется vps/vds или выделенный сервер. Если же вы взяли shared-хостинг, глупо рассчитывать на безотказную работу. Точно такая же ситуация будет и с другими shared-хостингами.
То же самое было. Еще хуже - в пути может быть только часть раздела (не все символы) и этот путь попадает в индекс Яндекса, а основной путь выбрасывается из индекса, как дубль. Решал вводом meta canonical и модификацией компонент, которые теперь добавляют canonical в < hea der >
Обновлял Старт с 12.5 на 16.5 - 4 версии всего, но в админку не закачалось куча файлов с иконками и js-скриптами. Пришлось руками копировать разделы с рабочей версии 16.5 на обновляемую. Потом проверка сайта - исправление выявленных расхождений в структуре базы, которые автоматом не исправились, потом полная переиндексация. И это простенький сайтик на Старте. Так что - готовьтесь к веселым событиям. Но да, сделать все можно, даже без обращения в тех.поддержку. В ТП сделают все это самостоятельно, предполагаю, все те же самые действия, только дольше по времени из-за медленного отклика.
Согласен, сам попался на потерю времени при желании верно указывать в sitemap.xml времени поста - после изменения поста, время остается старым. Пришлось делать танцы с бубном. Разбираться в методах формирования штатной процедуры создания sitemap по истечении нескольких часов копания года надоело, плюнул - сделано через такое недокументированное спагетти, что желание пропадает очень быстро.
Подождите, у вас сервер падает? Если нет, то все нормально - *nix использует имеющуюся память под разнообразные кэши и буфера. Сам по первости пугался - память стремилась к 0, потом поизучал темы - так и должно быть.
А у меня чуть сложнее: - проверяю на наличие стоп-слов в сообщении (в том числе html теги <a href) - проверяю на замену символов в слове на другом языке - проверяю на количество точек в имени email - проверяю на наличие стоп-email - .htaccess на странице с формой со списком IP спамеров.
В результате, спам идет очень редко.
Кстати, очень хотелось бы получить google-капчу штатным способом (пока битрикс предлагает только свою капчу, которая уже давным-давно разгадывается ботами)
Да. Александр - в базе хранятся только данные файлов (ссылка на место на диске, его параметры и имя файла), сами файлы хранятся на диске. По идее, битрикс должен удалять файл при удалении ИБ, но, на сколько я знаю, мусор из брошенных файлов остается. Поэтому, контролируйте этот момент самостоятельно: обработчики на удаление ИБ с заданным id. Легко проверяется - заведите ИБ, создайте файл, затем грохните ИБ и посмотрите наличие файла. Мне кажется - он останется. Давно не проверял, нарно с версии 12.5 еще.
Инфоблоки, тип данных - файлы, множественное, доп.свойство - привязка к пользователю (хотя, можно сделать название элемента ИБ = id пользователя и дальше его везде использовать). Фактически, файлы будут храниться в обычных директориях, не а базе. В базе только их id. В базе хранить файлы, просто безумие.
Причин может быть масса - например, это взломанный хостинг. Почему бы вам ни заархивировать весь сайт, развернуть у себя локально, проверить все (в том числе базу и .htaccess, а также .js-скрипты, которые могут подгружать данные + проверить служебные файлы битркса (например развернуть дистрибутив вашей версии и накатить с дистрибутива все служебные файлы поверх вашего)), а затем не перенести на новый хостинг.
У меня самого до сих пор есть несколько проектов на 12.5 версии, который не обновляю в силу ряда причин. Их не взломали, не сбрутили. Да и Битрикс уже давно очень и очень взломостоек. Так что, либо у вас ломанный хостер, либо украдены пароли с ftp/ssh/админки (возможно брутфорс).
По ссылкам, которые открывают страницы - смотрите логи, куда идет первоначальное обращение, куда делается редирект, смотрите файл .htaccess, смотрите файл urlrewrite.php, 404.php в корне. Но если система скомпрометирована, может быть все, что угодно, вплоть до модификации ядра. (Поэтому делайте все на локальной точной версии работающего проекта)
Да, производитель не обязан поддерживать систему без подписки на обновления. (Вы, правда, думаете, что кто то будет тратить силы/средства/время на поддержку устаревшей системы?) Покупая свою систему вы соглашались с этими условиями. Поэтому все претензии направляйте своей жабе и только.
Вам дали советы, можете ими пользоваться или проигнорировать, это ваше дело, но пожалуйста, больше не нужно нытья на несправедливость.
P.s. вставка кода может быть и закодированным способом, типа eval(), в котором обфусцированный код. (Есть несколько файлов самого битрикса с таким кодом, но их единицы и они в ядре. Можете дистрибутив и сравнить эти файлы с вашими. Все остальные файлы с такими вставками будут уже подозрительными)
Никак. Битрикс можно определить ВСЕГДА. Даже на уровне защиты от копирования (посмотрите отпечаток в response header), название переменных в куках, название директории bitrix, директории uploads, bitrix/admin/ и т.д.). И эти признаки скрыть нельзя (весь двиг завязан на таких особенностях), а все сервиса определяющие использованные на сайте CMS с этими признаками прекрасно знакомы. Да и с этической точки зрения, участвовать в мошенничестве по обману заказчика не хорошо (каждому воздается жизнью по его заслугам).
Scrooge, сначала попробуй сделать (да хотя бы спроектировать), потом будете рассказывать, как это просто реализовать, а до тех пор вы - сказочник для новичков. Да, к слову, я сам разработчик на Битриксе и админ. И да, мне не нужно раздавать советы, тем более тем людям, которые очень плохо понимают тему и задачу. И, пожалуйста, тоже не пишите пустые воздухосотрясательные и бессмысленые фразы "легко".
Да, Битрикс классная система, но как быть с 1.000.000 товаров (агрегатор товаров с нескольких магазинов) и импортом 70.000 новых товаров в сутки? Дорогой сервер, лучше кластер не предлагать .
В "FILTER_NAME" => "arFilter" указываете имя фильтра, а в фильтре пишете в массиве список элементов, которые не должны попасть в выборку.
$arFilter = array("!ID" => array( "10001", "23456", "345345"));
В принципе, задача решабельна - ajax-ом пересылаете список выведенных элементов и в компоненте включаете их в фильтр для исключения. Затем компонента получает новую группу случайных элементов за исключением уже показанных и отдает их ajax-у. Плюс отдает еще и список ранее выведенных элементов. Тогда ajax добавляем список текущих элементов к списку ранее выведенных и если будет еще запрос на вывод новой группы случайных элементов, отправит список исключаемых компоненте. Т.е. на каждом новом запросе будет расти список исключений для фильтра. Немного геморойно, но коли решили из..., то вот вам решение.
Как же вы из разобьете на части, если 15.000 руб ограничение в МЕСЯЦ? Не будешь же предлагать пользователю платить 2 месяца подряд. Тут выход, похоже, только один - делать предупреждение для товаров, стоимостью более 15.000 руб, что заплатить можно всеми способами, кроме электронных денег или владелец должен быть персонифицирован (т.е. для него снимаются ограничения в сумме 15.000 р.) Чтобы не заморачиваться - отключать электронные платежные систему, оставляя только платежи с карточек, квитанциями и перечислениями с р.сч.