Александр Маджугин

Если фреймворк под который ты пишешь везде использует <?, то на самом деле пофиг и я использую короткую версию.
Дело в том, что нет никакого "правильно" или "лучше" выбитого в граните. И надо понимать как будет использоваться ваш код. Если он не отделим от другого, где уже стопятцот раз написано <?, то все равно. Во всех других случаях <?php.
Для тех кто не понимает как и что он пишет есть PSR. Таким образом если вы не знаете что лучше использовать - пишите <?php. Как только сможете понимать, что лучше использовать - можете начинать использовать то, что лучше.

$filter = Array (
"LOGIC"=>"OR",
   array( "LOGIN" => 'ключевые | слова'),
   array( "NAME" => 'ключевые | слова'),
   array( "EMAIL" => 'ключевые | слова')
);

Так не работает?

А что толку что вы напишите свою привязку? Пользователь должен выбирать не из 18000, а из 4 (к примеру)?
Ну тогда просто удалите 17996 и оставьте 4 нужных. А если ему выбирать из 18000, то ему придется выбирать из 18000.
И кстати, почему флажки? Если у вас свойство не множественное - должен быть выпадающий список.

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

Но есть еще один нюанс - если у вас данные прилетают из 1с - зачем их вообще редактировать на стороне сайта? Какой-то не правильный подоход. Либо меняйте на стороне сайта и плюньте на импорт из 1с (трансформируйте элементы hl в элементы обычного IB), либо продолжайте управлять из 1с и в этом случае вам всеравно, сколько там тысяч флажков.

На самом деле не понятно что вы спрашиваете.
Если вам надо вывести один, первый элемент выборки, то тогда прислушайтесь к совету serginhold - установите лимит в 1 элемент.
А на худой конец вы ведь всегда можете в своем коде, который привели, заменить
while($ar_fields = $test_elements->GetNext())
на
if($ar_fields = $test_elements->GetNext())
И получить тот же самый эффект - отображение первого элемента выборки.

НО!
Вы пишите что-то про url и вряд ли вам нужно выводить один и тот же элемент (первый попавшийся) на многих разных страницах.
Следовательно у вас проблема вовсе не с тем что нужно показать один элемент вместо нескольких, как вы думаете и спрашиваете, а в том, как выбрать НУЖНЫ для этой странице элемент.
Если у вас страница однозначно ассоциирована с элементом не важно каким способом, то ваш фильтр должен выбрать один элемент и даже с while вы должны получить нужный вам результат.
Отсюда вопрос - в какой переменной запроса и какой идентификатор элемента вы передаете на странице?

На самом деле часто, очень часто, исполнителю достается такое ТЗ, что лучше его бы и правда не было. Типичные ошибки:
1 ТЗ содержит противоречивые требования, либо требования которые ведут к неявному противоречию.
2 ТЗ требует конкретные способы и/или технологии реализации логики, не совместимые, или плохо совместимые с логикой.
Обычно эти пункты присутствуют вместе и взаимно дополняют и обогащают друг-друга. Вот последний пример, правда в нем только пункт два:
Клиент захотел систему поддержки пользователей. Система должна принимать жалобы от пользователей на сайте, далее передавать их в 1С и со стороны 1С с ними должны работать менеджеры. В платформе на которой сделан сайт, есть уже модуль технической поддержки, хоть и примитивненнький, но от него много-то и не надо - форму для приема заявок и бэкенд для учета заявок в БД. Однако клиенту этого показалось мало и он нашел модуль стороннего разработчика который добавлял инструменты работы менеджера с жалобами на сайте без доступа в админку, чат с клиентом, отчеты по жалобам. Этот модуль согласовали в длинной череде инстанций, включили в ТЗ и выкатили нам.
Наша задача свелась к написанию обмена данных с 1С и выпиливанию инструментов менеджера, чата и отчетов т.е. ВСЕГО функционала модуля, кроме формы заявки, которая уже была реализована штатным функционалом, а здесь только повторялась и работала чуть хуже. Ну еще у этого модуля был свой бэкенд, поэтому пришлось писать обмен по недокументированному бэкенду.
Я потом составлял отчет и прикинул в процессе, что в целом клиент переплатил примерно в 6 раз, за то, чтобы задача была реализована так как он хочет, а не так как надо было.
И такое ТЗ даже не каждое второе. И вот он нахрен не надо.

А как представлены ваши абзацы?
Я бы делал это на базе обычных компонентов коментариев основанных на форуме, но для этого абзац нужно как -то представить в виде объекта данных, чтобы у него появился некоторый id по которому можно бы было связывать с ним его ветку комментариев. Самый просто метод "в лоб" это хранить каждый абзац отдельно как элемент ИБ, но это жутко неудобно. Я бы делал так - пусть абзацы это просто абзацы (тег p) в html поля DETAIL_TEXT элемент ИБ, тогда, уже на клиенте, им можно присвоить с помощью js id основанном на id элемент ИБ и номер абазаца в тексте.
Записывал бы этот id в какой-нибудь атрибут data-paraid и опять же js бы добавлял ко все элементтом с атрибутом data-paraid возможность открыть popup c iframe, в котором был бы обычный компонент комментариев.
Как-то так, в общих чертах.

У вас наверняка в настройка компонента меню ROOT_MENU_TYPE == top и CHILD_MENU_TYPE == top
Сделайте так - пусть файл .top.menu.php будет только в верхнем уровне.
Файлы .top.menu.php в каталогах разедлов переименуйте в .subtop.menu.php, а параметр CHILD_MENU_TYPE измените на subtop
Ну и почитайте как работает компонента меню и параметры ROOT_MENU_TYPE и CHILD_MENU_TYPE

Удалите модуль поиска вместе с таблицами. Установите назад и заново индексируйте сайт.
Казалось бы какая связь? А иногда помогает.

В папке /bitrix/modules никакой модуль случаем не переименовывали?
Попробуйте удалите из /bitrix/modules все левые модули. Прямо перенесите оттуда все каталоги модулей которые вам не нравятся временно в другую папку. Если заработает - возвращайте по одному.

Разработчиков битрикс как собак после дождя. Все вам sergafon ответил правильно - битрикс это просто CMS. Любая качественная верстка подойдет. Просто некоторые компоненты могут чуть сложнее кастомизироваться, но вряд ли они у вас будут.
Самая частая проблема от верстальщиков с которой я сталкиваюсь это кроссинг блоков. Но это плохо не только для битрикс, а вообще для чего угодно.
Пример:

<div>
Корзина
<div>здесь пункты корзины</div>
<div>
Итого стопятцот рублей
Тут форма заказа
</div>
</div>

Корзина и Итого в ней это один блок. А форма заказа - другой. Если теперь нам понадобиться отделить одно от другого, то вместе с корзиной мы оторвем открывающий div что кончится плачевно.
Вобщем верстать надо так, чтобы любой смысловой блок мог быть изъять из страницы без последствий.
Если есть интерес к разработке - пишите: madzhugin@yandex.ru

Зайдите на страницу просмотра списка разделов. Выведите на нее все разделы. Отметь галками их. Нажмите кнопку редактирования: joxi.ru/12Mx7bPSME4Lbm а затем ничего не меняя кнопку Сохранить. Радуйтесь.

Любая. От количества товаров ну никак не зависит требование к железу сервера. Разве что к объему диска.
В целом сайт будет бегать даже на шареде с полугигабайтом памяти. Вы же не собираетесь выводить все товары на одной странице, правда?

Все зависит от условий работы. Например от посещаемости. Будете ли использовать умный фильтр? Если да, то тут конечно шаред отпадает.
А что с импортом товаров? Будете каждый день все 150000 апдейтить? Или же будет добавляться пара товаров и на паре будет меняться цена?

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

Грубо говоря мобильное приложение битрикс это браузер без адресной строки с доступом к некоторым функциям платформы из js.
Какую вы мобильную версию запилите на сайте - такой сложности и будет ваше приложение. И да - сложность может быть любой, так как js тьюринг-полный язык ;)

Для этого проекта - любую. Вообще нет никаких требований. PHP с сохранением в файлы справится не говоря уже про БД. NoSQL не нужен, если в вашей школе меньше миллиона учеников.
Если бы проект не для конкурса а для работы, я бы предложил Битрикс, как это не странно - редакции Старт хватит за глаза, но главное преимущество - возможность быстро и легко создать приложения для всех мобильных платформ просто из вэб версии. Правда за сборку придется отдать под 50тыр, но так это же под все платформы.

Легион их. Я использую EditThisCookie - можно просматривать, менять удалять - чо хочешь делать.