Trionikl SR написал: через две недели битрикс сайт удалит?
Нет, битрикс не удалит сайт, однако его посещение будет заблокированно. Что это значит? Это значит что по истечению данного период вместо сайта будет отображаться только черная надпись на белом фоне и ссылка, по которой вы сможете ввести логин+пароль текущего администратора и новый лиц. ключ.
Сам же контент сайта (то что вы вводили в инфоблоки и таблицы, а так же код компонентов и т.п.) останется на месте, однако вы его посмотреть напрямую не сможете.
Конечно же дебажить 1) Составляете список дел, которые производились до появления такого поведения. Возможно обновили какое-то ПО, например версию php подняли или битрикс обновляли. 2) Изучаете логи ошибок сервера. Возможно поставили сторонне ПО или был модифицирован вывод. 3) Банально вставляете die('123'); по коду продукта пока не найдете где косяк
Лариса Дробина написал: Может, кто-то подскажет, что в данном случае делать?
Например можно при удалении приложения (событие) так же удалять свои поля. Это звучит логично, но если они общие (т.е. могут использоваться не только вашим приложением, но и хранить какую-то полезную информацию по архивным задачам в целом) то такое поведение не очень ожидаемое.
Альтернативный вариант - если поля по сигнатуре совпадают с вашими полями (т.е. и там и там совпадают коды, множественность, тип), то просто не создавать поля, а использовать имеющиеся.
Еще один альтернативный вариант - сохранять названия полей в конфигурации (options) на устанавливаемом портале, а код генерировать динамически, но есть шанс что при многократной установке приложения будут множество полей, поэтому этот метод обязательно использовать вместе с первым пунктом (т.е. удалять поля при удалении приложения).
Александр Хазов написал: В противном случае, создавало бы ее.
Самое быстрое и простое что приходит на ум как разработчику: написать активити которое бы выполняло поиск компании по криетрию и возвращало ID найденных компаний, а вы бы уже на выходе смотрели: есть записи - в одну ветку, нет - в другую.
Рустам Киньябаев написал: Если кто понимает о чем речь подскажите пожалуйста и решение в двух словах хотя бы. Спасибо!
Судя по вашему описанию я могу предположить что есть некая страница с input'ами (их можно добавить или удалить со страницы через JS). Есть кнопка, по нажатию на которую происходит отправка этих XML ID на сервер, выполняется поиск товаров по переданным XML ID и добавление в корзину.
По-умолчанию Битрикс не умеет добавлять в корзину по XML ID, только по ID. Скорее всего в тестовом задании у вас проверяют:
1) Знание JS (способность манипулировать DOM, AJAX) 2) Знание Core Bitrix Framework (то как вы реализуете endpoint для приема запроса) 3) Знание Bitrix Framework API (как CIBlockElement::getList, добавление товара)
Олег Юсупов написал: Прочитал на форуме что с версии 7.4.4 начинаются тормоза с БД
Скорее всего тормоза связаны не с этим. У нас есть многие порталы которые обновились с Bitrix Env 7.4.3 на Bitrix Env 7.4.4 и никаких явных тормозов мы не заметили.
Скорее всего при разработке сайта была допущена ошибка и наряду с блоками был установлен и дополнительный php-код, таким образом редактирование страницы через визуальный редактор строжайше запрещено, из-за того что при редактировании происходит физическое изменение страницы, что и произошло у вас.
Вам потребуется помощь квалифицированного разработчика чтобы он проверил логи и восстановил работоспособность страницы.
Тимур Битимов, например вы не обновили Битрикс24 или закончилось действие лиц.ключа. Не скажу что это единственные проблемы, но зачастую именно они и приводят к подобной проблеме.
Виталий, я проверил 2 Битрикса и не обнаружил такой функции в этом файле, а затем я полез в php.net и не обнаружил такой функции в php. Проверьте файл, возможно кто-то ручками его подправил.
Есть только одно гарантированное решение данной ситуации: настроить и использовать свой почтовый сервер. Дело в том, что Битрикс пытается отправлять от дефолтного отправителя все письма, а письма формируются от тех почтовых ящиков что подключены в публичной части.
Ел котят на морозе, правильно ли я понимаю суть задачи: у вас есть инфоблок (предположим в нем 100 статей) и вы хотите вывести постраничную навигацию для него (по 10 элементов на страницу). Таким образом у вас будет 10 страниц по 10 элементов на каждой. Далее вы хотите добавить еще 1 элемент, который хотите вывести вначало таким образом, чтобы на первой странице было 9 элементов, а на последующих до 10.
Я вижу несколько вариантов решения данной ситуации: 1) Написание своего компонента для контроля над номером выводимой страницы и количеством элементов на этой странице. Это потребует достаточно широких познаний в области постраничной навигации, кешировании.
2) Добавление нового поля 'типа элемента' (для того чтобы отделить особый элемент от других) и созданием технического элемента. Это довольно простой и прямолинейный способ решить задачу без сильной кастомизации.
Антон Быцко написал: создаст ключ со значением только в массиве текущего внешнего пользователя, или же ключ создастся у всех пользователей, но у локальных будет пустым?
Для текущего пользователя в его текущей сессии.
Цитата
Антон Быцко написал: При учете, что данная проверка может вызываться и по 100 раз на странице. Может быстрее будет работать просто проверка preg_match по ip и не городить лишнего?
preg_match всегда будет медленнее. Т.е. 1 раз посчитать и 100 раз достать быстрее чем 100 раз посчитать.
Не вижу несоответствия. Там же написано: "для подсчета", а не для фильтрации самой выборки.
Цитата
Ел котят на морозе написал: Далее в шаблоне /bitrix/templates/ /components/bitrix/news.list/catalog-table/template.php получил значение
Если бы вы почитали документацию, вы бы знали что запрещается править код ядра. Ядро продукта - файлы, находящиеся в директории /bitrix/modules/ а так же файлы системных компонентов: /bitrix/components/bitrix/.
Т.е. ваше решение сразу становится не поддерживаемый и как следствие не эффективным (хоть и решают исходную задачу).
Цитата
Ел котят на морозе написал: И вот возник главный вопрос можно ли, имея ID элемента, добавить как-то этот элемент к не нарезанному на страницы навигации массиву с элементами.
Нельзя, потому что у вас нет "нарезанному на страницы навигации массиву с элементами". GetList формирует запрос в MySQL и получает результат выполнения запроса и в нем уже только эта страница. Легитимный вариант - при выводе на страницу проверять либо номер текущей страницы, либо другие параметры запроса.
2) После пункта 1, у вас появится более-менее структурированный вопрос, основанный на конкретике: делаю {1 + 2 + 3} получаю { 456 }, ожидаю {6}. Этот вопрос можно погуглить и уже после этого задать на форуме.
Возможно, мой ответ может показаться вам бессмысленным или оскорбительным, в таком случае можете просто проигнорировать это сообщение (нет нужны на него отвечать или писать что-то в догонку).
Вадим написал: Как лучше и легче реализовать, чтобы на каждой странице был свой баннер?
Самое простое что приходит на ум: - Инфоблок с баннерами: -- Название и Краткое описание (если на баннере нужен текста) -- Картинка для анонса - сам баннер -- Ссылки (множественные строки, куда будете добавлять ссылки где должен отображаться баннер)
Свой компонент который по текущему url будет доставать все элементы у которых он находится в ссылках.
news.list тут особо не поможет, а вот свой компонент + хранение свойств в отдельных таблицах даже очень. И разместить свой компонент нужно в некеширумой области, если у вас комплексный компонент то в шаблоне компонента news самое место (но не news.*)
Виктор Таран написал: Я не буду сейчас расписывать в эпитетах зачем вообще было применять msmtp
Применяется потому что он простой: его просто установить, просто конфигурировать и не нужно обслуживать. Вы тут предлагаете революцию и перейти от msmtp к postfix, а ведь это не менее большое изменение чем отказ от httpd в пользу php-fpm. Кто будет брать на себя ответственность в миграцию msmtp -> postfix? Предлагаете заботливо переложить на плечи вендору?
То что вы предлагаете конечно похвально и очень нужно, но вот на практике позиция Битрикса много лет увы другая: видите явные грехи - делайте платную услугу для их устранения и делайте на этом деньги.