Денис Шаромов (Все сообщения пользователя)

Если захотите разобраться, можете почитать тут: http://dev.1c-bitrix.ru/community/blogs/howto/?category=340

Сергей, а почему вы отказались от использования простого штатного инструмента резервного копирования и переноса?

Техподдержка решит конкретную проблему с работой кеша, если она есть.
По вопросам производительности могут быть даны общие рекомендации и ссылки на документацию и блоги на нашем сайте. Если вы захотите разобраться самостоятельно, информации на сайте более, чем достаточно.

Но требовать от техподдержки заниматься оптимизацией сайта - не правильно. В рамках экспертизы уже идет анализ вашего кода на вопрос наличия узких мест.

Но, хоть и может казаться, экспертиза производительности не окупает себя. Анализ конфигурации сервера и кода требует погружения в проект высококлассных специалистов, зачастую с привлечением ведущих разработчиков. На эту задачу обычно уходит несколько дней.

Поэтому мы популяризуем монитор производительности и методики оптимизации сайта. Сам процесс сегодня уже максимально упрощен. Монитор производительности даже сам создает индексы и показывает их эффективность. Но по-прежнему не хотят разбираться. Чтобы перестали говорить, что битрикс виноват, осталось только сделать кнопку "оптимизировать мой код и исправить ошибки сервера".

Или лучше "сделать быстро!".

Друзья, тема целесообразности написания валидного html обсуждалась много раз.
Ничего кроме флейма из этого не выйдет. Давайте закроем тему пока она умещается на одной странице,

Коллеги, контакты автора в первом сообщении.
Тема ушла далеко в другое русло, простите, закрываю.

А если проблема возникает непредсказуемо в разное время, то поможет такое решение: http://dev.1c-bitrix.ru/community/blogs/Kobzar/1970.php

Исследовал эту тему когда еще монитор производительности входил в топовые редакции: http://dev.1c-bitrix.ru/community/blogs/howto/1044.php

Сейчас он доступен везде, надо этим пользоваться!



Денис Диденко, хостер не обязан и не всегда в состоянии исследовать ваши скрипты в поисках самого ресурсоемкого кода.

Алексей Задойный,  поддерживаю.

Установите в php.ini

Это делается таким образом: поднимается копия портала, на неё ставятся обновления. Затем вручную проверяется работоспособность, в случае необходимости делаются правки уже без порчи ядра. Когда копия работает - на основной портал накатываются обновления и делаются уже известные правки.

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

Используйте "здоровый" путь.

Юрий, вы больше извлечете пользы если направите свою энергию в позитивное русло

Посмотрите здесь:
http://dev.1c-bitrix.ru/community/webdev/user/11948/blog/add-your-item-to-the-event-log/

Попробуйте так:

Отлично, на этой мажорной ноте закроем тему: short_open_tag никуда не денутся в PHP 6.

Алексей, а в каком тикете решается проблема?

Нет, хостер - это компания или системный администратор, кто делает настройку системы. Техническая поддержка не решает вопросы настройки сервера, не важно, работает он на BitrixVM или нет.

В данном конкретном случае Николай собирался сам изучить проблему, но обращение ему не направили. Пожалуйста, укажите номер тикета чтобы исправить это недоразумение.

Ошибка была давно исправлена. Если обновления не помогают, возможно, что-то сработало не так.
Пожалуйста, создайте обращение в техподдержку.

Мы делаем разовый перенос на коробку если у вас уже есть коммерческий ключ КП.
При этом надо понимать, что если купленная редакция не содержит модули с Б24, то данные будут утеряны (например, CRM).

Процедура следующая: после решения о переносе и покупке ключа создается обращение в ТП, где указываются все данные Б24 и ключ. С этого момента работа на Б24 может продолжаться, но новые данные перенесены не будут.

В течение суток (на рабочей неделе) мы делаем перенос. Если заявка поступит с утра, можем успеть в течение дня.

В итоге вы получаете ссылку на полную резервную копию КП, восстановить можно на любом окружении (например, BitrixVM) через restore.php

dmitry.sidorov, мы должны сделать какие-то выводы из вашей цитаты?

asy2, вы пришли на форум разработчиков чтобы узнать реальную ситуацию или доказать, что тут все неправы? Больше похоже на второе.


Использование short_open_tag настолько удобно для разработчиков, что получило повсеместное распространение. Много лет назад мне пришлось править код после публикации на хостинге т.к. там были включены NOTICE (без возможности выключить). Сегодня такой хостинг никому не интересен в принципе. Тоже самое относится к short_open_tag.

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

Если вы не будете прислушиваться к своим потребителям - останетесь за пределами рынка.

Если надо только наполнять контент сайта, т.е. работать с инфоблоками, то никакой проблемы нет.

Но если вы привлекаете внешнего разработчика, ограничить его возможности достаточно тяжело.

Русский язык не ставится через систему обнвлений.
Необходимо установить русский дистрибутив: он содержит русский и английский языки.

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

Тема не имеет смысла: перенос возможен только вместе с базой данных и ядром. Просто введите локально свой ключ, установите обновления, потом выполните полный перенос.

Проблема в том, что к изображениям применяется фильтр резкости. Чтобы избежать этого - передавайте пятым параметром пустой массив.

Вероятнее всего, ошибка с правами.

Пользователь от которого настраивается модуль DAV, должен обладать правами для доступа к ящикам других пользователей. В Exchange 2007 даже Администратор по умолчанию не имеет таких прав, для этого логина их необходимо добавлять.