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

Странный вопрос - вы же понимаете что вам будут советовать то с чем работают советчики. Даже те, кто работал со всеми тремя платформами, любят на самом деле что-то одно.
Вот я бы раставил то что вы предлагаете ровно так же как стоят теги. При этом хочется отметить что Joomla вообще не CMS.
Сам делал бы на Bitrix + Vue, но отказавшись от фронтальной части CMS. Т.е. использовал бы Buitrix как фреймворк и админку.

Я вначале не обратил внимение что:

после чего выделен первый элемент массива в переменную $a = 2LbGeAo

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

Но если бы этот элемент не изымался из строки, то востановление было бы возможно так как я описал ранее. Мой прежний ответ ниже:

Сначала нужно восстановить порядок символов в короткой строке. Это можно сделать отыскав ее среди подстрок длинной. Это несложно - разбейте длинную на массив подстрок: $shuffle = Array ( [0] => 2LbGeAo [1] => MTJkZjA [2] => 2M1ZjA5 [3] => YTljMGZ [4] => AzZjFkY [5] => hYmUyZW [6] => 1NThhMD [7] => Y= ), для каждого элемент сделайте разбиение на массив, сортировку и объединение назад в строку. У вас получится еще один массив Array ( [0] => 2AGLbeo [1] => AMTJZkj [2] => 125AMZj и так далее. Объедините эти два массива используя второй как ключи: Array ( [2AGLbeo] => 2LbGeAo [AMTJZkj] => AkMTJjZ ... и в ключе равном вашей короткой строке найдете ее исходный вид - 2LbGeAo

Далее дело техники - 2AGLbeo указывает текущее расположение подстрок, а 2LbGeAo то которое вам надо востановить. Разбиваете обе строки на массивы так чтобы они были ключами: $a1 = [2=>0,A=>1,G=>2,L=>3 ... и т.д.] и $a2 => [2=>0,L=>1,b=>2,G=>3 ... и так далее]

Создаете новый массив $result длиной равный количеству подстрок, и в цикле перебираете элементы $a=>1:
for ($a1 as $k1=>$i1) {
$i2 = $a2[$k1]
$result[$i2] = $shuffle[$i1]
}

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

Смотрите содержимое $arParams. Оно будет таким:

Array(
      ...
      "MENU_TITLE" => "О гостинице"
      "~MENU_TITLE" => "О гостинице"
      ...
    )

или в /local/img/ПутьКРазделу/pic.jpg

Все варианты рабочие. У всех есть плюсы и минусы и практически все эти плюсы и минусы можно игнорировать если вы не используете систему контроля версий, вроде git.

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

Проблема не в этом. Вот только вчера ругался с верстальщиком - проблема в том что вы используете jquery и ajax - не надо так. Точнее можно, но очень оккуратно, понимая что происходит.
А в прниципе они противопоказаны друг-другу, потому что ajax обновляет DOM, а jquery работает с событиями которые навешиваются на элементы DOM.

Решния такие:
1 Самое простое - перевесить все события на document или body. Ну т.е. у вас есть скрпит какой-то который навешен на '.baybutton' скажем как-то так$('.baybutton').click Меняете его на $(document).on(.baybutton','click'' или как-то так. Соотвественно, когда вы заменете ajax'ом эту кнопку, событие на ней останется, так как висит на документе.

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

И да - битрикс тут не при чем.

Столкнулся с одноим банком, который хреновато защищает вклады. По сути, только сличением лица с фото в паспорте предлагают ограничить безопасность. Отсюда и вопрос - насколько реально подменить лицо, чтобы сделать его как у другого человека?

В принципе вполне реально - нужно взломать ваш сервер и использовать его как прокси. Так что если вы придумаете какую-то другую защиту, например с помощью ключей api, то их так же можно получить взломав ваш сервер. Даже проще чем ip - не нужно повышать права до root - достаточно читать данные доступные серверу.

Да - защита только сличением IP не самая технологичная и надежная. Но все остальное еще менее надежное. Более того всем остальным нельзя усилить защиту по IP.

P.S.
Да, есть другое способ еще - взломать саму платежную систему, но опять же - тогда и IP подменять не надо будет.

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

Создавать под каждую задачу тестовую площадку

Ваши специалисты абсолютно правы.

но это неоптимально по куче различных причин

Можно услышать хотя бы две? Я не вижу таки причин, при использовании веток Git.

P.S. Битрикс тут не при чем.

> 1. Если команды, расположение директорий коренным образом не такое как на 16.04 тогда придется по новой все настраивать - гимор еще тот
А что там может быть "не такое"? Я бы выбирал как раз 18.04, для перехода с 16.04 - он будет самым безболлезненным.

P.S.
а ftp - то зачем может понадобиться в 2020 году?

Там скорее всего статику отдает nginx так что htaccess не при чем.
Возможно в настройках nginx есть правило запрещающие доступ к этим файлам.
Или сами файлы недоступны для чтения сервером, просто по причине прав на сами файлы/папки (не знаю как это в виндовс работает)

При чем тут битрикс? В смысле причем он как источник проблемы? Вы сделали две одинаковые страницы, а теперь спрашиваете почему они одинаковые? Поразительно.
А собственно почему это страницы отображающей один и тот же товар должны быть разные тайтл и дескрипшин? Это что, разные товары?
Ну то-есть у вас проблемы не с битриксом, с логикой вашего каталога. Приведите в порядок логику и маркетинговый план.
Разберитесь каким должны быть тайтл и дискрипшен у товара.
Обоснуйте почему они у ОДНОГО И ТОГО ЖЕ товара должны быть разные и по каким принципам должны формироваться - дальше будет понятно что делать.


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

Можно ли добавить дополнительный функционал в существующие CMS?

Конечно. Иначе какой бы в них был смысл? Как правило CMS построена на каком-нибудь фреймворке, на котором хоть новую CMS можно создать.
То что вы пишите в этом вопросе ниже это вообще мелкие частности, а не "дополнительные функции".

Какие CMS есть для создания приложений для IOS и Android?

Вообще приложения для смартов создаются вовсе не на CMS, а к созданному приложению на любой CMS можно прикрутить интерфейс. Однако у Битрикс есть платформа для быстрого создания приложений прямо на базе сайта построенного на CMS.

Если это можно сделать, то CMS должно быть с открытым кодом?

Не обязательно, но желательно. Правда не сталкивался с CMS с закрытым кодом. Не знаю есть ли такие.

Каким образом происходит вставка дополнительной части кода в общий контекст?

Не знаю что ответить на этот вопрос...
Код пишется и интегрируется с в готовый продукт. Нет там никаких образов вобщем.

Специалистов каких CMS можно найти больше и чаще?

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

На мой взгляд вы выбираете между плохим и ужасным решением.
При этом не очень понятно каким образом 20 000 индексных страниц могут "нагрузить систему". Почему это с технической стороны должно быть хуже/тяжелее?
20 000 индексных страниц нагрузят вас - поддерживать такое превратится в мартышкин труд. Совершенно не понятно почему вы собрались делать на каждый раздел отдельную индексную страницу. Почему не сделать её одну на все разделы?

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

Ложная дихотомия тут. Почему вы полагаете что у вас выбор между комплексным компонентом и собственной индексной страницей для каждого раздела?
Сделайте три файла в каталоге - index, section и detail и разместите в них соответственно список разделов, раздел, и детальную страницу элемента.
Т.е. в index - catalog.section.list, в section - catalog.section и в detail соотвественно catalog.element.
Настройте нужным образом urlrewrite и это на мой взгляд лучшее решение. Можно конечно применить и комплексный компонент в одном индексном файле, но на мой взгляд это плохое решение - оно менее прозрачно, громоздко и может привести к ошибка в работе с url, так как перекладывает на вас контроль за настройками путей на сайте.

Добавлю к ответу Андрея (в принципе полностью верному), что вообще не стоит даже пытаться это сделать - используйте API и вы застрахуете себя от многих проблем в будущем.
Если вам необходимо действие как транзакция - этом можно организовать: гуглите "StartTransaction"

Подойдет любая. CentOS удобна только тем что для нее есть скрипт устанавливающий BitrixEnv, что очень удобно. В скрипте есть процедуры для настройки работы сокетов, выпуска сертификата летсэнкрипт и тому подобного.

Если вы сами в состоянии администрировать сервер и знаете что и зачем нужно - пойдет и Ubuntu.

Я использую и то и то.