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

Еще смотрим
/public_html/bitrix/js/main/core/core.js - в конце закодированное строка
/public_html/bitrix/modules/main/include/prolog.php - в конце закодированная строка
А еще все это и в кэш попало - чистим кэш

Что будет при попытке создания файла кэша? А если в кроне?

Благодарность за выкладку изменений!
Хм, у меня нет такого модуля, а на 2х из 3х сайтах в upload появились какие то лишние файлы. Значит правка только в файлах модуля vote будет не достаточна для закрытия дыры.
P.s. - зачем до сегодняшних проблем было обновлять битрикс, если все работало отлично на небольших информационных сайтах
P.s.P.s. Подумываю о переносе сайтjd с битрикса на что то другое (да хотя бы на WP)

Правила можно дополнить разрешеннымы адресами (аналогично для всех остальных):
<Files ~ "^(site_checker)\.php$>
 Order Deny,Allow
 deny from all
 # Здесь указать разрешенный адрес или адрес сетки с маской
 Allow from XX.XXX.0.0/16
</Files>

нет, д.б. так (у вас в начале немного мусора):

Еще немножко информации:

188.72.203.9 - - [20/Jun/2022:23:50:34 +0300] "GET /bitrix/tools/composite_data.php HTTP/1.0" 200 214 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/99.0.4844.82 Safari/537.36 Edg/99.0.1150.36"
188.72.203.9 - - [20/Jun/2022:23:50:35 +0300] "POST /bitrix/tools/html_editor_action.php HTTP/1.0" 200 383 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/99.0.4844.82 Safari/537.36 Edg/99.0.1150.36"
188.72.203.9 - - [20/Jun/2022:23:50:35 +0300] "POST /bitrix/tools/html_editor_action.php HTTP/1.0" 200 1 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/99.0.4844.82 Safari/537.36 Edg/99.0.1150.36"
188.72.203.9 - - [20/Jun/2022:23:50:36 +0300] "GET /bitrix/tools/sale_print.php HTTP/1.0" 200 30 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/99.0.4844.82 Safari/537.36 Edg/99.0.1150.36"

После этого оказалась создана директория на сайте:
/upload/tmp/BXTEMP-2022-06-21/11/bxu/main/8cb4fb53.......1afff015d10d791c6/
с файлами (права на все rw-rw-rw):
.log
1.log
default
pindex101.package

Любопытно содержимое файла .log:
a:8:{s:4:"hash";s:1:".";s:2:"id";s:1:".";s:12:"uploadStatus";s:8:"uploaded";s:13:"executeStatus";s:8:"executed";s:4:"name";N;s:4:"type";N;s:4:"size";N;s:5:"files";a:1:{s:7:"default";a:9:{s:4:"size";i:8445;s:8:"tmp_name";s:122:"/home/u/account/name-account/public_html/upload/tmp/BXTEMP-2022-06-21/11/bxu/main/8......d10d791c6/default";s:4:"type";s:10:"image/jpeg";s:4:"name";N;s:4:"code";s:7:"default";s:12:"uploadStatus";s:8:"uploaded";s:3:"url";s:133:"https : //мойсайт-ру/bitrix/tools/html_editor_action.php?bxu_info[CID]=1&bxu_info[mode]=vie... КБ";}}}

файл default представлен как тиа image/jpeg и содержит что от закодированное

Интересно, что попытки обращения с одного адреса были на /bitrix/tools/html_editor_action.php (POST)  и (GET) на  /bitrix/tools/sale_print.php и  /bitrix/tools/composite_data.php (в логах за весь день ни кто другой не обращался ни к композиту, ни к sale_print )

Полностью безопасно - много раз так делал: заходил в консоль и удалял либо весь кэш, либо кэш конкретного компонента (по названию директорий и содержимому файлов кэша видно, к чему он относится)

Может быть браузер закешировал результат? Попробуйте проверить работу в анонимном режиме браузера (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 не обновилось автоматически). Лечилось копированием всех служебных директорий Битрикса из текущего дистрибутива, затем проверки, исправления БД штатными средствами. Так что нужно готовиться к проблемам. Лучше всего, обновить свой отладочный сервер, затем после всех исправлений выложить на рабочий.