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

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

Проблема не в этом. Вот только вчера ругался с верстальщиком - проблема в том что вы используете 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 подменять не надо будет.

Там скорее всего статику отдает 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.

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

Но если мы будем переводить проект на реакт, то как мы будем писать php в нем?

Что это вообще может значить? PHP у вас это server side, а React это клиентское приложение.... Блин, я даже не знаю что дальше спросить... вы PHP в браузере собрались исполнять или JS интерпритатором PHP?
Это вот вопрос он лишен смысла чуть более чем полностью.

Ведь синтаксис реакта ( jsx ) не предусматривает php.

Да причем тут синтаксис? Среда исполнения не предусматривает php, а вы про синтаксис.

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

Если это сайт среднего размера, то нужно заложить не неделю, а несколько месяцев.

Т.е. получается одна часть проекта будет написана на реакте, а другая - нет? Это вообще как?

А что здесь может быть не понятного? Ну реалазиуйте сначала на реакте одну страничку, самую простую в отдельном шаблоне сайта. Будет у вас для переделанных URL один шаблон использоваться, а для не переделанных другой - без реакта. Не вижу никакой проблемы.

У кого то есть подобный или близкий к этому опыт? Что посоветуете? Как грамотно перевести проект на реакт в таком случае?

Выше написал:
1 Сначала разрабатываете шаблон для одного раздела сайта на React, так как буд-то других разделов просто не существует.
2 Пишите соотвествующий бэкенд который будет отдавать данные для этого вашего шаблона.
3 Переводите этот раздел сайта на React.
4 Эксплуатируете неделю, подчищая косяки.
5 Выбираете еще один раздел сайта поменьше и переводите его аналогичным образом.
6 В этом месте у вас уже должно быть понимание где вы наложали с архитектурой, какие накопились костыли, и в чем фундаментальные изъяны того что вы сделал. Тут вы должны остановиться и выкинуть всё что сделали раньше. Я не шучу - просто выкинуть и начать перерабатывать эти разделы с нуля...
7 Теперь вы знаете что делать дальше.

Если диск вашего сервера поддерживаем OPAL - просто смените пароль. Если нет и он удаленный - у вас нет надежного способа уничтожить данные на нем.
В принципе то что вы собираетесь сделать сработает. И даже из ssh вас не выкинет скорее всего. С чего бы?
Но как правильно заметил Alexey Dmitriev нет смысла стирать все - лучше стереть только важное. Правильное решене у АртемЪ - забить диск данными до отказа, но только после этого еще раз стереть мусор и еще раз забить до отказа. Повторить раза 3-4 это даст больше уверенности что данные нельзя будет востановить чем просто dd.
Но нет никаких гарантий что у хостера не осталось резервных копий :)

1 Битрикс тут совсем не при чем.
2 Нужно как вам нужно. А как вам не нужно - не нужно.
3 Я бы сделал все без www.

Сейчас у вас ничто вообще не убирает www. Просто при входе с http происходит редирект на https://site.ru
Было там www или не было ему решительно все равно. Вы написал - если http - редиректить на https://site.ru, не зависимо от того что было до этого.

Для удаления www нужно добавить что-то вроде:
RewriteCond %{HTTP_HOST} ^www\.(.*)$
RewriteRule ^(.*)$ https://%1/$1 [L,R=301]

(не проверял)

Аплойд на ЯД по вэбдав де-фактор не работает с октября: Где хранить бэкапы после кончины Яндекс.Диска?

Никак.

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

Совсем другое дело если бэкендер вообще не дотрагивается до верстки и js, но тогда у вас должны быть договоренности по форматам обмена и общее представление о том как будет работать проект.

Так что вариант оставить все как есть только один - вы договариваетесь об интерфейсах и тогда он делает бэк, и не касается фронта вообще, а вы делаете фронт, в том числе и взаимодействие с бэком.
Если вы хотите спихнуть на него написание js для ajax - он просто не справится не имея доступа к исходникам и видя только собранные данные.