Пароль по умолчанию для принтеров Zebra

[РЕШЕНО] Unknown field definition `sort` (sort) for \Bitrix\Highloadblock\HighloadBlock Entity. (100)

В админке Битрикс, если зайти в Рабочий стол -> Контент -> Highload-блоки выскакивает такая ошибка:

[Bitrix\Main\SystemException] 
Unknown field definition `sort` (sort) for \Bitrix\Highloadblock\HighloadBlock Entity. (100)
/home/bitrix/www/bitrix/modules/main/lib/orm/query/chain.php:346
#0: Bitrix\Main\ORM\Query\Chain::getChainByDefinition
	/home/bitrix/www/bitrix/modules/main/lib/orm/query/query.php:3445
#1: Bitrix\Main\ORM\Query\Query->getRegisteredChain
	/home/bitrix/www/bitrix/modules/main/lib/orm/query/query.php:1864
#2: Bitrix\Main\ORM\Query\Query->addToOrderChain
	/home/bitrix/www/bitrix/modules/main/lib/orm/query/query.php:2427
#3: Bitrix\Main\ORM\Query\Query->buildQuery
	/home/bitrix/www/bitrix/modules/main/lib/orm/query/query.php:933
#4: Bitrix\Main\ORM\Query\Query->exec
	/home/bitrix/www/bitrix/modules/main/lib/orm/data/datamanager.php:513
#5: Bitrix\Main\ORM\Data\DataManager::getList
	/home/bitrix/www/bitrix/modules/highloadblock/admin/highloadblock_index.php:52
#6: require(string)
	/home/bitrix/www/bitrix/admin/highloadblock_index.php:1
----------

Ошибка возникает в файле «\home\bitrix\www\bitrix\modules\highloadblock\admin\highloadblock_index.php«,  где «\home\bitrix\www\» корневая папка сайта на сервере.

use Bitrix\Highloadblock as HL;

// select data
$rsData = HL\HighloadBlockTable::getList(array(
    "select" => $lAdmin->GetVisibleHeaderColumns(),
    "order" => array($by => mb_strtoupper($order))
));
$rsData = new CAdminResult($rsData, $sTableID);
$rsData->NavStart();

Меняем  строку 52 на:

"order" => array('ID' => 'ASC'),

и на странице списка хайлоад блоков в админке,  вуаля, появляется наш список, отсортированный по возрастанию ID.

ЗЫ(рь): Помните, что Вы правите ЯДРО!!! Ай-яй-яй. Пока Битрикс не исправят ошибку, придётся либо не обновлять систему, либо всё время править файлы.

My SQL. Заменить подстроку (часть текста) во всех строках таблицы

UPDATE `table_name`
SET `name_field_1` = REPLACE(`name_field_1`, "заменяемый текст", "на что меняем"), `name_field_2`= REPLACE(`name_field_2`, "заменяемый текст", "на что меняем")
WHERE `name_field_where` =  'bla-bla-bla';

table_name — название таблицы, в которой хотим найти и заменить текст

name_field_1, name_field_2 — названия полей таблицы, в которых нужно заменить часть текста

Редирект с алиасов на основной домен, на который куплен SSL сертификат

Приключилась однажды такая история: был сайт, допустим my.site. Был приобретен SSL сертификат на my.site и на www.my.site. По ТЗ было еще несколько доменных имен, с которых пользователь должен был попадать на my.site. Но они не были «прописаны» в сертификате.

Конфигурационные файлы сайта на Bitrix-VM и их пути на сервере:

• /etc/nginx/nginx.conf – основной конфигурационный файл nginx (заменяется при обновлении).
• /etc/nginx/bx/ – основной каталог для хранения конфигурационных файлов виртуальной машины.
• /etc/nginx/bx/conf/ – каталог с общими конфигурационными файлами, чаще всего подключенных непосредственно в конфиг сайта.
  • bitrix.conf – для сайтов, у которых не включен композит (меняется при обновлении).
  • bitrix_general.conf – используется для любого сайта (меняется при обновлении).
  • ssl.conf – настройки сертификата по умолчанию (меняется при обновлении).
• /etc/nginx/bx/maps/ – каталог хранения общих и персональных переменных сайта, представленные в виде карт nginx.
• /etc/nginx/bx/settings/ – каталог с персональными конфигами под сайт. По умолчанию (если установлено соответствующее обновление) будет содержать настройки для хранения временных файлов сайта (BX_TEMPORARY_FILES_DIRECTORY) и отдачи этих файлов через nginx.
• /etc/nginx/bx/site_available/ – каталог с существующими сайтами (или виртуальными хостами).
  • s1.conf и ssl.s1.conf – конфиги сайта по умолчанию для http и https соответственно.
  • bx_ext_<SITE_NAME>.conf и >bx_ext_ssl_<SITE_NAME>.conf – конфиги сайтов для http и https соответственно.
• /etc/nginx/bx/site_enabled/ – каталог с подключенными сайтами (в большинстве случаев, симлинки на site_available).
• /etc/nginx/bx/site_ext_enabled/ – каталог с конфигами сайтов, не связанных с Bitrix-окружением.

В nginx были следующие настройки:

В файле /etc/nginx/bx/site_available/bx_ext_my.site.conf (Обратите внимание, что в названии файла нет слова «ssl»)

server {
listen 80;
server_name my.site www.my.site alias1-my.site www.alias1-my.site alias2-my.site www.alias2-my.site xn--100500-2nfa5e3a2e.xn--p1acf;
# и ещё 100500 других алиасов

# тут еще всякие настройки включая редирект на https
}

В файле /etc/nginx/bx/site_available/bx_ext_ssl_my.site.conf (Обратите внимание, что в названии файла есть слово «ssl»)

server {
    listen 443 ssl http2;  
    server_name my.site www.my.site alias1-my.site www.alias1-my.site alias2-my.site www.alias2-my.site xn--100500-2nfa5e3a2e.xn--p1acf;

В такой вот конфигурации, все замечательно работало, если заходить по основному домену, будь то с www или без (помним про сертификат). Но как только пытаемся зайти на любой из алиасов, то трындец, всё пропало!

— И сертификат у вас не такой, и вообще все у вас не такое, буду отображать что хочу! — сообщил тут же браузер, и показал даже и основной сайт на хосте, а второй или даже третий!

Ок, гуголь хром… В файле /etc/nginx/bx/site_available/bx_ext_my.site.conf (Снова обратите внимание, что в названии файла нет слова «ssl») выносим/переносим алиасы и редирект с них на основной домен в отдельную секцию server{}. Порядок важен: сначала секция server с алиасами! Во втором файле также.

server {
listen 80 ;
server_name  alias1-my.site www.alias1-my.site alias2-my.site www.alias2-my.site xn--100500-2nfa5e3a2e.xn--p1acf;
server_name_in_redirect on;
rewrite ^/(.*) https://my.site$1 permanent;
}
server {
listen 80;
server_name my.site www.my.site;
# и ещё 100500 других алиасов

# тут еще всякие настройки включая редирект на https
}

В файле /etc/nginx/bx/site_available/bx_ext_ssl_my.site.conf (Обратите внимание, что в названии файла есть слово «ssl»)

server {
listen 443 ssl http2;
server_name alias1-my.site www.alias1-my.site alias2-my.site www.alias2-my.site xn--100500-2nfa5e3a2e.xn--p1acf;
return 301 https://my.site$request_uri;
}

server {
    listen 443 ssl http2;  
    server_name my.site www.my.site;

Вот и все. Позже разберусь почему на 80 порту  в первом файле, я написал rewrite, а во втором return 301.  Правильно, скорее всего, в первом файле тоже return 301  прописать. Так поисковики поймут куда им идти, в смысле на какой сайт пользователей посылать…  ну, вы поняли? 🙂

shell_exec не работает в crontab в php скрипте

Задача: сравнить размеры файлов для контроля изменений в них. Заставить работать по крону.

При запуске скрипта из браузера все в порядке. Отлично работала функция $file['size']=filesize("/path to file/my_scrip.php"); При попытке запуска скрипта по крону, размер файлов не подсчитался, то есть функция filesize не сработала. Заменил filesize("/path to file/my_scrip.php"); на shell_exec('stat -c %s /path to file/my_scrip.php'). То же самое. При запуске скрипта из браузера и в консоли SSH команда stat -c %s /path to file/my_scrip.php показывает размер файла, а по крону не работает.

В консоли SSH команда stat -c %s /path to file/my_scrip.php показывает размер файла, а по крону не работает.

На просторах интернета нашел решение:

chdir($root_path."/"); // $root_path - абсолютный путь к папке нашего скрипта.
$arFile['size'] = trim(shell_exec('stat -c %s '.escapeshellarg($main_dir . "/" . $dir))); // Выполняем команду stat...
$current_dir = getcwd(); //Получаем 
chdir($current_dir);</code>

В моем случае директории ($root_path."/" и $current_dir) совпадают. Позже проверю и поправлю статью.