Евгений Смолин (Все сообщения пользователя)

Может быть браузер закешировал результат? Попробуйте проверить работу в анонимном режиме браузера (Ctrl+Shift+N)

As for escaping the "#", try \%23 with an [NE,L] flag on the rule.

Может рестартануть apache2/nginx нужно после изменений?

VisualStudioCode + плагины, SublimeText без оплаты + плагины, evolution версия PHPStorm - все бесплатно

Может проще на utf-8 перейти? Это не так сложно, а решает массу проблем сразу. К тому же что там дальше будет с cp-1251 одному богу известно.

bin-log нужен для репликации и восстановления данных в InnoDB-движке (при сбое). Если репликация не используется, незачем хранить binlog в несколько суток. Да и вообще, незачем его такой громадный хранить.

expire_logs_days = 2 - ограничить время хранения 2мя днями (сколько не жалко)
max-bin-log-size = 500M - ограничим размер в 500М (или сколько вам не жалко. Учитывайте, что InnoDB не сразу может писать данные в базу, т.к. является транзакионным движком. Но уж за пару минут-то запишет)

Еще можно попробовать добавить:
binlog-cache-size = 128K
max-binlog-cache-size = 100M - макс. размер кеша бинлога

Пробуйте.

Естественно, после добавления или изменения настроек, перезапустить сервер MySQL

Для своего случая (Debian 9, PHP 7.1.33, только Apache, кодировка нужного сайта CP1251, другие сайты - UTF-8  ) решил проблему так:
- проверяем установленные локали на сервере:
locale -a
C
C.UTF-8
POSIX

ага, нет cp1251

- запускаем  dpkg-reconfigure locales
 выбираем из списка:
ru_RU.CP1251 CP1251
ru_RU.UTF-8 UTF-8

на следующей странице по умолчанию выбираем ru_RU.UTF-8 UTF-8 (UTF-8 сайтов просто физически больше, да и дебиан настроен на UTF-8 в консоле)

дальше система все ставит и настраивает сама.

- в /bitrix/php_interface/dbconn.php добавляем:

setlocale(LC_ALL, 'ru_RU.CP1251');
setlocale(LC_NUMERIC,'C');

- перезапускаем веб-сервер (в моем случае только Apache): /etc/init.d/apache2 restart
(или service apache2 restart)

Проверяем: Тестирование системы -> Полное тестирование системы

Ошибка ушла!
При этом в системе все нормально работает и с UTF-8 сайтами в других каталогах

 

Честно, я не знаю как просто и быстро определить тип лицензии, кроме плясок с бубном

Хм, ну тогда читаем список модулей и на основе анализа определяем тип лицензии.
Список модулей, в зависимости от версии: https://www.1c-bitrix.ru/products/cms/license.php  

\bitrix\modules\main\classes\general\version.php определяет константу SM_VERSION с текущей версией системы и дату SM_VERSION_DATE

Да, можете. Отключаете не используемые модули, удаляете их физически с диска. Оставляете только те, которые входят в требуемую редакцию сайта (в данном случае "Старт"). Потом обращаетесь в тех.поддержку с просьбой понизить редакцию и сможете дальше обновляться уже на условиях под новой редакцией.

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

Посмотрите вот это : https://dev.1c-bitrix.ru/support/forum/forum6/topic29679/   - может поможет?

В 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, потом поизучал темы - так и должно быть.

Например, посмотрите статейки по запросам "unix что потребляет память", типа _https://www.it-rem.ru/linux-kto-sel-vsyu-pamyat.html

А у меня чуть сложнее:
- проверяю на наличие стоп-слов в сообщении (в том числе html теги <a href)
- проверяю на замену символов в слове на другом языке
- проверяю на количество точек в имени email
- проверяю на наличие стоп-email
- .htaccess на странице с формой со списком IP спамеров.

В результате, спам идет очень редко.

Кстати, очень хотелось бы получить google-капчу штатным способом (пока битрикс предлагает только свою капчу, которая уже давным-давно разгадывается ботами)