Версия php 7.2.2 не поддерживается битриксом. Используйте 7.0 или 7.1
Что касается сборки своего, можно долго не заморачиваться и использовать BitrixEnv. Снимет много геморроя и сразу сделает двухуровневую конфигурацию Nginx -> Apache -> PHP
Олег Ярчук, есть пара способов: прочитать документацию к шаблону или найти в коде шаблона вызов и убрать его. Я без понятия какой шаблон Вы купили/используете (так как это НЕ стандартный переключатель тем) и кода шаблона вашего я тоже не знаю.
kozlov_igor написал: Система восстановила всё и поехали работать дальше, но вопрос так и остался - почему при заливке файлов через форму нельзя восстановить сайт СТАНДАРТНЫМ способом. Это не оттестировано или вообще не предусмотрено?
А какой размер одного архива? Напишите тикет в техническую поддержку, с номером сюда, пожалуйста.
Егор Мантусов, ну так все верно: история - это текстовая запись об изменениях. Нельзя получить все изменения статусов, но можно получить все изменения сделки и путем поиска регулярными выражениями найти именно смену статуса.
И потом внимательно читаем описание модуля: События (под событиями подразумевается перенос комментариев к контактам, компаниям, сделкам, прикрепленные файлы, информация о звонках и письмах) Этап переноса гарантированно поддерживает обработку 10 000 событий.
То есть: события это не изменение сделки/компании/контакта, а лишь то, что находится в живой ленте, а это вовсе не история изменения поля.
Николай Ковальский написал: Ощущение, что просто где-то в настройках стоит галка производить автоматическую регистрацию, не спрашивая об этом пользователя...
Ну так там и есть эта настройка) Посмотрите параметры компонента
Ксения, для начала нужно выяснить что именно тормозит: посмотрите панель того же битрикса - он скажет куда уходит время (хотя бы направление).
Затем по-порядку: 1) Смотрим самые тяжелые страницы через штатный инструмент: https://dev.1c-bitrix.ru/learning/course/?COURSE_ID=41&LESSON_ID=2731 Уменьшаем время генерации страниц (где-то отказываемся от кеширования в пользу отложенных ajax-функций, где-то наоборот вводим кеширование).
2) Через Google pagespeed можно посмотреть неоптимальные скрипты, тяжелые картинки и это пофиксить (Минимальный результат должен быть не ниже 80, и к тому же все зависящее именно от Вас должно быть выполнено, а не просто цифра 70%). Подробнее про все это можно почитать в руководстве самого Google: https://developers.google.com/speed/docs/insights/rules
3) Затем нужно посмотреть на порядок рендеринга страниц (может помочь: https://www.webpagetest.org/) Нужно переработать DOM-структуру так, чтобы нужный контент был выше и верстка была проще (увидите покадрово как загружается ваш сайт)
И это, если мы говорим только про сайт. Есть еще серверные настройки (надеюсь у Вас VPS/VDS, а не shared-хостинг), с которыми тоже нужно работать.
Александр Фадеев, приватный ключ не обязательно должен быть в pem-файле. У nginx всего 2 параметра (насколько мне известно): ssl_certificate и ssl_certificate_key. Причем в ssl_certificate указывается именно полный pem-файл (от юдоменного до вышестоящего).
Однако тот факт, что битрикс требует отдельно файл сертификата и файл цепочки, наводит на мысль, что он сам это сделает (или должен сделать, но почему-то не сделал).
Александр Ким, проверьте ссылкой симантека - он скажет какой лишний, а какие отсуствуют. Комодо иногда лишние поикладывает (не обязательно все сертификаты должны быть, там в цепочке дело)
Артем Липовой написал: Что же делать в моей ситуации?)
Начните с: 1) Проставление всем полям инфоблока параметра "Показывать в списке" 2) Ручками попробуйте внести ваши свойства в b_lists_field 3) Очистки всего кеша (cache, managed_cache, stack_cache).
P.S. А после, если Вы будете использовать универсальные списки, всегда читайте апи и не верьте своим глазам. Свойства для УС добавляются через CListPropertyField
Могу ошибаться (каждый раз вспонимаю как это делается), но:
1) COMODO вроде как уже сразу выдает сертификаты в PEM, только называются они .crt / .key Поэтому файлы сертификата и ключа получаются переименованием:
Денис Громов, тогда нужно смотреть таблицу b_sender_posting_recipient по POSTING_ID и смотреть кому не отправилось. Потом смотреть логи почтового сервера (привлекая системных администраторов, или получая логи почтового сервера).
Статусы могут быть: 'Y' - Нет результата 'N' - успешная отправка 'E' - Ошибка отправки 'W' - Ожидание отправки 'D' - Не отправлять
P.S. Без доступа к серверу это проблему координально не решить.
Карина написал: необходимо посылать на почту менеджеру, что такой-то заказ оплачен.
Штатно нет таких уведомлений. Если хотите чтобы появилась такая возможность - создайте идею. Если Вам эта механика нужна уже в ближайшее время, то можно заказать разработку у партнеров или фрилансеров (коих много и на этом форуме).
Что касается общей механики, то тут есть пара вариантов: 1) Обработка на событиях (если менеджеру нужно знать про каждый такой заказ) 2) Периодическая обработка (раз в сутки менеджеру будет приходить письмо со всеми заказами)
Первый случай - на обработчик события Второй - на агента
1) Объем сайта никак не влияет на его вес. Нужно уменьшать скорость генерации страницы и весь ресурсов (картинки, скрипты, css). Бекапы на скорость загрузки не влияют. (если конечно пользователь не заходит во время создания бекапа) 2) Бекапы которые лежат в облачном хранилище не занимают физического места на сервере и соответственно не влияют на скорость загрузки