Не секрет, что ошибка в файле init.php (используется для подключения своих функций) приводит к полной потере работоспособности сайта и невозможности что-то исправить без доступа к файлу через ftp/ssh/напрямую с диска. Как же поступить, когда нужно писать свои функции, а доступ - только через веб? Один из наиболее простых способов - вынос всего вашего кода во внешний файл и подключение его примерно так:
Внимание! код дан только в качестве примера! перед использованием убедитесь в адекватности!
При таком подходе вы сможете безболезненно редактировать и допускать ошибки в файле functions.php, не боясь оказаться у разбитого корыта неработающего сайта без возможности как-то повлиять на ситуацию
Если мы допустили ошибку в файле functions.php, с параметром &noinit=Y мы можем зайти в админку, открыть этот файл, но мы не можем исправить ошибку, изменения не сохраняются. Какой тогда в этом смысл? Или я что-то делаю не так? Ну хотя, конечно мы можем переименовать его временно, исправить ошибку, и потом вернуть. Как вариант конечно лучше, чем вообще ничего. Спасибо)
Обновили на сервере PHP до версии 5.2.9 и обнаружили, что теперь в .htaccess не работает установка mbstring.func_overload =2 А вот и описание причины:
Цитирую - самое важное отсюда:
It's not possible to change it in perdir configs anymore. Fix for bug #43227 changed this. Apparently Rui forgot to document it..smile:)
Вот собственно и вся новость. Думаю, что она будет полезна многим и снимет ряд вопросов. У себя будем откатываться назад на PHP 5.2.6
UPDATED: подошло решение из комментариев. Принудительно включили глобально mbstring.func_overload =2, поставили по умолчанию кодировку 1251, а на нужных сайтах включили через .htaccess utf8.
Коленько Сергей, А как для локального сервера хост прописать, у меня к примеру на Open Server каталог с сайтом testsite.ru, я прописал в php.ini , но не работает, показывает ноль при установке, может на локально по другому прописывается? [HOST=testsite.ru] mbstring.func_overload=2
Андрей, я по сделал по совету в мануале Open Server, т.е. для каждого хоста копируется в директорию файл с настройками для апач, где и прописывается mbstring.func_overload=2 Впринципе всё работает, но в столбцах local и global по нулям
Не все знают, что у стандартных компонентов 1С-Битрикс есть много красивых шаблонов, которые практически никогда не используются. Например, один начинающий разработчик спросил, как сделать такое же прикольное голосование как вот здесь (в виде 5-ти квадратиков и выбора через AJAX). Проблема не нова - я , что многие возможности 1С-Битрикс остаются за кадром разработчиков. Не претендуя на лавры мега-программиста, хочу рассказать совсем о другом: 1. Что у стандартных компонентов часто есть другие шаблоны, а не только .default 2. Что комплексные компоненты "Новости" и "Каталог" иногда похожи, а иногда сильно различаются. Итак, задача: 1. Выдать голосовалку не в детальном товаре, а на странице со списком товаров. 2. Выдать ее на AJAX стандартными средствами
Ррешение (для среднеподготовленного человека, методом копипасты): В каталоге нет голосования. Зато оно есть в комплексном компоненте "Новости", в детальном просмотре элемента. Идем в этот шаблон и видим такой код:
Собственно. он нам и нужен. Копируем его куда-нибудь.
Теперь решаем задачу выдачи его в списке элементов. Например, в ТОП элементов каталога. Вставляем данный код в шаблон компонента "bitrix:catalog.top" куда-нибудь, где он должен выводиться. Я вставил его в таблицу после вывода <?=$arElement["PREVIEW_TEXT"]?>. Теперь нужно сделать, чтобы голосование выводилось для нужного нам элемента. Меняем строку
"ELEMENT_ID" => $ElementID,
на
"ELEMENT_ID" =>$arElement["ID"],
и - ура - голосовалка работает!
Теперь внешний вид. Идем в папку с шаблонами компонента bitrix:iblock.vote и видим там два шаблона: по-умолчанию (страшненький выпадающий список) и ajax. Вторая проблема тоже решена. В итоге вызов компонента получился вот таким:
Одна из самых распространенных платформ хостинга - это CPanel. В целом в ней все хорошо, но по умолчанию есть такая проблема - дополнительные домены для аккаунта по умолчанию создаются внутри папки public_html основного домена.
К сожалению, при настройке многосайтовости в Битрикс это приводит реально к большим проблемам с ЧПУ и работой комплексных компонентов - фактически, они перестают работать из-за того, что Битрикс неправильно считает что многосайтовость настроена по первому (обычно никому не нужному способу), и толкает настройки ЧПУ в соответствующий файл urlrewrite на главном сайте.
Поэтому при работе на CPanel необходимо, чтобы ваш хостер разрешал создание поддоменов вне папки public_html
Вот и все нюансы.
Дополнено: Пример, как этого добиться, решение проблемы 1. Создаем основной сайт 2. Добавляем другой домен, подпапкой в папке основного сайта 3. Создаем в битрикс 2 сайта по второму способу многосайтовости 4. в корень каждого сайта естественно, кладем .htaccess и urlrewrite.php 5. создаем два инфоблока новости 6. создаем в каждом сайте папку "news", кидаем в index.php комплексный компонент новости и включаем в нем ЧПУ 7. в результате в первом сайте, который верхний, в urlrewrite.php появляются две такие записи
Получается странная вещь: 1. На втором сайте urlrewrite.php не работает 2. на первом сайте почему-то идут ссылки на второй сайт как на подпапку, хотя такого не предполагалось 3. Поскольку на обоих сайтах могут быть одинаковые разделы, но с разными настройками, реально они перестают работать. ну и другие проблемы, с этим связанные.
Решение (подсказано читателями): 1-й вариант - требовать от хостера включения возможности размещать дополнительные домены вне папки public_html 2-й вариант - создавать сначала "фиктивный" домен, а потом уже создавать нормальные домены. тогда они будут все на одном уровне и все будет ок
Петров Роман написал: Создаем основной сайт 2. Добавляем другой домен, подпапкой в папке основного сайта 3. Создаем в битрикс 2 сайта по второму способу многосайтовости
Наверное, все знают, что один из лучших хостеров для 1С-Битрикс - это Очень много как партнеров 1С-Битрикс, так и просто сайтов работают на этом хостинге.
Для моей компании Timeweb в настоящее время является основным хостинг-партнером - у нас размещено на нем более 220 аккаунтов клиентов. Мы работаем с Timeweb в режиме интегратора и не скрываем для наших заказчиков, что хостинг предоставляет именно Timeweb, а мы являемся только агентами.
В целом линейка тарифов у Timeweb достаточно сбалансирована до определенного уровня - пока сайт не начнет генерировать высокую нагрузку на тариф Eterno[B]. После этого владельцу сайта необходимо либо переходить на Premium тариф, либо выбирать VPS а затем выделенный сервер. Как правило, это случается всегда неожиданно и владелец сайта психологически не готов платить после 825 рублей/месяц например, 4000 рублей/месяц.
В последнее время многие партнеры 1С-Битрикс высказывают нарекания в сторону Timeweb из-за "неожиданного" и "необоснованного" роста нагрузки на аккаунты клиентов. Несомненно, бывает всякое, однако, хочу поделиться нашим опытом снижения нагрузки на достаточно крупный интернет-магазин.
Итак, в сентябре 2011 мы запустили проект для одной из ведущих региональных компаний на российском рынке информационных технологий - . Все было хорошо, нагрузка на сервер была совсем маленькой - в октябре 2011 нагрузка на процессор колебалась от 100 до 200 единиц, а нагрузка на базу - менее 30 единиц. И как вдруг раз - и со 2-го ноября нагрузка на базу резко возрастает - до 20 000 единиц!
Первая реакция - "Что случилось?" и "Так не может быть! Это сбой подсчета статистики!". Думаю, что такая реакция была бы у любого разработчика. Естественно, что первым делом мы подумали, что выросла посещаемость. Но нет - прирост был не очень значительным, и это не должно было сильно повлиять. Вторым - что Timeweb ошибается. Здесь важно рассказать о том, как считается нагрузка на аккаунт. Для мониторинга за нагрузкой CPU используются данные утилиты sa. В качестве показателей нагрузки mysql используется процессорное время, затраченное за выполнение sql-запроса (используются percona'вские версии mysql)
Предположение, которое сразу же высказал нам Timeweb - что нагружает импорт - требовалось проверить. После обсуждения директор Timeweb, Дмитрий Тарасов, сделал нам предложение, от которого сложно было отказаться - выделил нам на время тестирования отдельный сервер, на котором мы могли бы проверить все свои предположения. Сервер был настроен также, как и стандартный хостинг-сервер, и у нас были те же самые права. Т.е. у нас не было паролей от root (ни от сервера, ни от MySQL).
Сначала мы решили проверить, не вызван ли рост нагрузки тем, что на старом сервере другие аккаунты стали "есть" больше ресурсов и в результате у всех выросла нагрузка. Увы (или к счастью) это не так, и статистика Timeweb действительно не зависит от загрузки сервера.
Далее наступила очередь импорта-экспорта данных. Сайт очень активно обменивается данными с 1С, и, как мы понимаем теперь, скорее всего в ноябре объем реально обмениваемых данных резко вырос. Оптимизация скриптов импорта позволила выявить несколько мелких и часто незаметных ошибок: - выполнение запроса в цикле - выборка по неточному совпадению (в паре мест использовался Like вместо точного совпадения) В результате загрузка была снижена в более чем 5 раз!
Дополнительно, мы включили в импорт проверку на изменение данных. Теперь, если данные не изменились, система не обновляла их. Это позволило снизить нагрузку еще сильнее. Итоговая нагрузка на MySQL снизилась более чем в 10 раз!
Красный - нагрузка на MySQL до оптимизации Синий - после устранения недочетов импорта Зеленый - после доработки импорта (убрали обновление неизмененных данных)
Дополнительно мы решили оптимизировать загрузку страниц. Важно отметить, что проект непростой - у компании несколько городов с несколькими магазинами в каждом городе. Цена на товар зависит от города, а наличие в городе зависит от наличия в магазинах. В итоге на вид простая главная страница генерировала достаточно много запросов к базе данных (когда был хит мимо кэша). Оптимизация кэширования и работы компонентов позволила выиграть от 30 до 50% скорости загрузки страниц, и, хотя это и было необязательно, это снимет много потенциальных проблем в будущем.
Результат оптимизации страниц: Синий график - среднее время генерации страницы до оптимизации, красный - после оптимизации. Как ни странно, большая часть оптимизации свелась к замене нескольких выборок в шаблоне сайта на кэшируемый компонент, оборачиванию в кэш части динамической информации, получаемой на каждой странице (например, служебные данные о магазинах выбранного города) и убирание автоматической загрузки капчи в комментариях к товару. При кажущейся простоте работа потребовала достаточно серьезного анализа данных монитора производительности 1С-Битрикс. Не оптимизированным остался только поиск - по нему будут отдельные доработки.
Результат борьбы с нагрузкой вы можете увидеть на рисунке:
На графике хорошо виден всплеск нагрузки на MySQL в начале ноября и последующий спад в зеленую зону после оптимизации. Падение нагрузки на CPU в крайнем справа значении графика - это из-за переноса на другой сервер (сбросилась статистика).
В целом по результату оптимизации мы сделали такие выводы: 1. Для интернет-магазинов в стоимость включать проверку не только под нагрузкой на посещаемость, но и уточнение объемов и частоты обмена данными 2. Механизмы расчетов, которые изучаются в курсе "Численные методы" в университете, нужно применять и в вебе. Пока сайт маленький или данных немного - работает любой способ. Затем, при росте объема данных, рост нагрузки может стать квадратичным из-за маленькой ошибки в вызове скрипта (например, где-то стоит маленький полный перебор). 3. Статистика Timeweb не врет. 4. Теперь у нас есть администрируемый Timeweb сервер со спецтарифами для "тяжелых" клиентов.
Важно отметить еще несколько вещей, которыми я руководствовался при принятии решений: 1. VPS и сервер в Германии - не панацея. Связано это с необходимостью администрировать сервер и VPS. Я являюсь поклонником shared хостинга, потому что в этом случае за нашими сайтами следят профессионалы. И они быстрее заметят проблему, потому что это - их работа. В случае VPS или своего сервера затраты на администратора будут очень значительными. 2. Сами мы хостингом заниматься не хотим. Это очень дорого и требует значительных вложений, прежде всего в сотрудников - администраторов и поддержку.
Всю работу по оптимизации сайта выполнял , наш технический директор
Благодарности: Дмитрию Тарасову, директору , за помощь в решении сложной ситуации.
Петров Роман, я и не с целью начать спор написал, а просто внести альтернативное мнение по вопросу. > всё это время могут идти обмен с 1С В обсуждаемом проекте использовался не Битрикс. Никаких фоновых процессов не было. > выполняться агенты по cron В моем сообщении выше: "В панели таймвэба отключил крон".
Буквально недавно проблема повторилась у партнеров, которым мы когда то порекомендовали этот хостинг (он реально был хорошим в прошлом). Без каких либо изменений в сайте (работ никаких не велось) и посещаемости (какая была - такая и осталась) в 10 раз прыгнула нагрузка на ЦП. Во избежание недоразумений повысили тариф на время решения вопросов с переносом.
Если хотите - могу провести тот же опыт - переадресовать всех на другой сервер, выключить крон, и наскриншотить графиков за неделю после.
Вообще есть определенная степень солидарности вот с этим товарищем.
Если посмотреть вот тут, то не только у меня:
Не исключаю, что там разная ситуация на разных серверах или разные по качеству каналы связи с регионами, но у текущего хостера таких проблем не обнаружено.
тогда у вас три пути, по сути: 1. смириться и сменить тариф 2. плюнуть и сменить хостинг 3. попытаться добиться справедливости от таймвеб - обращениями в техподдержку и собственными тестами.
Коллеги, в предыдущем сообщении у меня спросили - как мы тестируем битриксовые сайты из маркета? Делаем ли мы это на демо-версиях или это реальные установки для клиента, и мы рассказываем наши ощущения?
В общем, это реальные установки для клиентов. Мы стараемся не продавать что попало, и потом публиковать отзыв о результатах. У нас есть свои рекордсмены - под десяток покупок и установок.
Группы на сайте создаются не только сотрудниками «1С-Битрикс», но и партнерами компании. Поэтому мнения участников групп могут не совпадать с позицией компании «1С-Битрикс».
Группы на сайте создаются не только сотрудниками «1С-Битрикс», но и партнерами компании. Поэтому мнения участников групп могут не совпадать с позицией компании «1С-Битрикс».
Ну хотя, конечно мы можем переименовать его временно, исправить ошибку, и потом вернуть. Как вариант конечно лучше, чем вообще ничего.
Спасибо)