Андрей Кондуров, пробуйте обновиться до 7.4.1, что тут скажешь. Екатерина Шемаева, вот пример того, что особо не поуправляешь через панель модулями php. кстати, как видите на скриншоте есть два файла по тому-же xdebug - и с суффиком .disabled и без него. так сразу и не поймешь, включен модуль или нет. а с учетом того, чтобы он не включился при обновлении, надо отключать двумя файлами, основной переименовывать в .disabled и создавать пустой файл.
Екатерина Шемаева, про управление модулями из меню машины я в курсе. вопрос именно про то, чтобы модули не включались после обновления php, т.к. многие обновляют машину, при этом не замечают что включился xdebug, который существенно замедляет работу сайта. выходит только проверять после обновления, либо действовать с пустыми файлами для ненужных модулей, как я описал выше?
побуду немного занудой: не APC, а видимо APCu - это немного разные вещи, в APCu отключен опкеш кода, а оставлен только функционал кеширования пользовательских данных.
кстати, частенько после обновления машины приходится править конфиги php и отключать не нужные модули. раньше думал, что достаточно следовать логике: /etc/php.d/15-xdebug.ini.disabled - отключен модуль, переименовываем: /etc/php.d/15-xdebug.ini - включен модуль и наоборот.
но после обновления php появляется файл /etc/php.d/15-xdebug.ini с включенным модулем. поэтому сейчас делают так: /etc/php.d/15-xdebug.ini.disabled - отключен модуль, в нем подключение нужного модуля (т.е. не пустой файл) /etc/php.d/15-xdebug.ini - пустой файл, чтобы при обновлении не включился.
при обновлении при этом появиться файл: /etc/php.d/15-xdebug.ini.rpmnew но ненужный модуль не включится
может кто знает как иначе можно php-модулями управлять, чтобы они при обновлении не включались?
Не запускается mysqld - нужно пускать вручную, при каждой перезагрузке
так установите мускул в автозапуск:
Код
systemctl enable mysqld # для centOS7
chkconfig mysqld on # для centOS6
Цитата
И у сайта по умолчанию (home/bitrix/www) настройки кодировки не под UTF-8
при обновлении некоторые конфиги сайтов переписываются, а некоторые - нет. в данном случае просто добавьте две строчки в настройки сайта в апатче: файл /etc/httpd/bx/conf/default.conf
вообще по опыту могу сказать, что машина удобна для быстрого развертывания, но она не отменяет необходимость администрирования, т.к. некоторые вещи нужно вручную донастраивать и добавлять.
Описанное решение в данном посте уже давно не актуально, т.к. давно исправлено на уровне дистрибутивов. Видимо у вас какая-то другая проблема, попробуйте для начала провести диагностику сервера данным скриптом: https://dev.1c-bitrix.ru/learning/course/?COURSE_ID=32&LESSON_ID=3262
ПРОБЛЕМА: В общем, при установке дистрибутива 9.5.6, после указания данных для соединения с БД и начале установки (побежал прогресс бар) получаем ошибку "ошибка установки главного модуля" и на этом все заканчивается.
РЕШЕНИЕ: Были опробованы дистрибутивы на других серверах, они работают. Я начал грешить, что проблема связана со свежеобновленным MySQL и не ошибся
...
create table b_group (
ID int(18) not null auto_increment,
TIMESTAMP_X timestamp(14),
ACTIVE char(1) not null default 'Y',
C_SORT int(18) not null default '100',
ANONYMOUS char(1) not null default 'N',
NAME varchar(255) not null,
DESCRIPTION varchar(255),
SECURITY_POLICY text null,
STRING_ID varchar(255),
primary key (ID)
)
Error:
You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '(14),
ACTIVE char(1) not null default 'Y',
C_SORT int(18) not null default' at line 3
...
Ага, есть ошибка синтаксиса SQL-запроса.
2) Выясняем из гугла, что за ошибка и почему возникает в этом месте. В итоге находим следующий момент:
3) далее открываем файл /bitrix/modules/main/install/mysql/install.sql и вносим в него правку: меняем указание типа полей с timestamp(14) на timestamp
Причем, если открыть sql-скрипт установки, допустим, модуля инфоблоков, то там запросы написаны верно. Предположу, что забыли исправить этот момент именно в sql-скрипте установки главного модуля.
После внесения этой правки установка идет как надо.
<?php
/*
* насколько я понимаю, механизм отложенных функций через эти же функции захвата вывода сделан.
* т.е. в итоге во время сборки страницы будет выполнено нечто:
*/
ob_start();
ob_start();
/* код компонента */
$out1 = ob_get_contents();
ob_end_clean();
$out = ob_get_contents();
ob_end_clean();
?>
есть некоторые сомнения по поводу кеширования, за вариант спасибо, опробую.
не совсем приминим. причина - (часто верстка шаблона диктует именно такое вложение компонентов), т.е. нужно сперва показать свойства товара, затем форму заказа, затем ссылку "вернуться к списку". т.е. по сути необходимо делать комплексные компоненты, в файле шаблона которого вызывать все необходимые компоненты, это решит возникающие побочные эффекты (их описал Dmitry Ban)?
Кирилл пишет: почитайте мануал о создании своих компонентов и создавайте а не скрешивайте. Это конечно если у вас есть опыт в php. А если нет то учите
опыт есть, документацию читал. что значит "создавайте, а не скрешивайте", дайте пожалуйста более развернутый ответ. Укажите на моменты в документации, если не трудно. Заранее спасибо.