rPman

Идеологически, любой контент от пользователя нужно считать опасным и проводить проверку. Самое простое - запретить все что не разрешено (т.е. буквально проводить анализ контента пользователя не на предмет поиска скриптов, а на список разрешенных элементов), да это сложно но иначе гарантий ты не получишь.

p.s. как минимум script тег блокируется (вроде бы можно разрешить), остаются еще куча мест где может быть активное содержимое типа css, svg, xslt,... в общем вопрос неплохого такого исследования.

Есть два основных направления
* устаревший, но не требующий javascript на клиенте - это разделение страницы на фреймы (iframe и frame) таким образом, чтобы изменяющиеся части попадали на свой фрейм
в этом случае будет мигать не вся страница а только изменяющаяся часть, и вообще то браузеры прекрасно это обрабатывают, даже курсор в формах остается на старом месте
Не рекомендую этот подход, он устарел и имеет смысл только если действительно нужно разрабатывать сайт для условий отключенного javascript (например tor/i2p сети).
Очень много логики можно реализовать на основе css, язык там уже на столько сложен и многофункционален что простые вещи типа отображение и смокрытие элементов на основе кликов - обычное дело.
Совет, чтобы мерцание не было видно, оптимизируйте ответ бакэнда таким образом чтобы ответ выдавался по времени быстрее некоторого порога (при его превышении страница будет мерцать)

* собирайте страницу с помощью javascript, вообще этот подход рекомендуется для всего сайта но меняет парадигму на SPA приложения, а так же немного мешает SEO через работу поисковиков, не полностью готовых к полностью динамическим страницам (это все решаемо, просто требуется прогрузиться в проблему по серьезнее)

Собирать на стороне клиента страницу можно по разному:

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

Интеллектуальная пересборка - полная аналогия разделения страницы на области соответственно логики их обновления как в решении с iframe, когда элементы на странице обновляются блоками ровно тогда и там, когда это нужно.

Как частный случай обновляется даже не структура html а только текстовые значения (и даже значения атрибутов), так как очень часто обновление имеет смысл для данных а не структуры, за исключением случаев когда есть списки и размеры их меняются. Этот подход спорный, я видел когда так реализовывали мультиязыковую поддержку (т.е. по умолчанию страница как бы пустая, а затем загружается языковой json и все элементы наполняются текстом соответственно уникальным id), несет некоторую нагрузку на процессор (незначительную, никто так не оптимизирует уже давно), требует некоторого учета при верстке (нужно везде прописывать минимальные размеры) но гарантированно не мерцает даже на медленных соединениях, так как данные можно сначала загузить полностью и только потом менять на странице
------------------------------

Обновления со стороны сервера можно получать двумя способами
- периодическими опросами (генерирует квадратичную нагрузку на сервер при увеличении одновременно работающих пользователей) но очень простой в реализации
- воспользоваться websocket/events, эти технологии специально созданы для того чтобы сервер мог оперативно сообщить какую то информацию клиентам без постоянных опросов и лишней нагрузке на сервер, но требует поднятие websocket сервера, удерживающего открытые соединения, для тех кто привык к http rest подходу с cgi короткоживущими приложениями, это может быть сложно, но результат того стоит

Полагаю вопрос в том как передать сразу несколько данных форм в пределах одного запроса?

Для этого в стандарте html forms существует возможность передачи списков, в этом случае имена полей должны быть вида "name[]" или "name[xxx]" где xxx это значение ключа соответствующего элемента в массиве (может быть не только число), в массиве на бакэнде значение элемента с именем name буде массивом, где ключ и знаение будут соответствовать xxx и значению, введенному в поле (для пустых скобок будет автоматически использоваться счетчик с 0)

<form method="post" action="test.php">
<input name="aaa[]" type="text">
<input name="bbb[]" type="text"><br>
<input name="aaa[xxx]" type="text">
<input name="bbb[xxx]" type="text"><br>
<input name="aaa[222]" type="text">
<input name="bbb[222]" type="text">
<input name="aaa[]" type="text">
<input name="bbb[]" type="text"><br>
<input type="submit">
</form>

выдаст массив $_POST:

Array
(
    [aaa] => Array
        (
            [0] => q
            [xxx] => w
            [222] => e
            [223] => r
        )

    [bbb] => Array
        (
            [0] => t
            [xxx] => y
            [222] => u
            [223] => i
        )
)

т.е. осталось только правильно сгенерировать нужную форму с правильными именами элементов

Универсально и полностью автоматически такое провести очень сложно.

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

Это и ddl изменения и правки данных.

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

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

Все это должна сделать программа миграции.

Хорошим подспорьем могут являться утилиты сравнения двух баз данных, с ddl точно видел готовые утилиты, дающие sql, то для данных обычно не так удобно. Проще под каждую ситуацию писать что то свое.

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

Проблема явно в процессе сборки чем именно и как она производиться?

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

Браузер и сервер это разные приложения, пока файл между ними не будет перемещен, никакие действия не возможны, кроме как локальные

p.s. Надеюсь речь идет о работе с файлом в браузере на javascript? а то к примеру штатная html form method=post и полем input type=file это прямая отправка файла на сервер

Правильно - исключить 'ручную' работу в процессе переноса релизных изменений в продакшен базу.
Т.е. задача разработчика делать скрипты, которые будут приводить базу данных предыдущей версии к следующей, при этом это не только обновление структуры (это кстати можно сделать автоматически, сравнив базы разных версий, гуглить ddl diff, к примеру для postgres это pgadmin shema diff) но и данные, например наполнение новых полей данными или к примеру в старой версии поле было текстовое в 'свободном формате', а в новой на его основе целая структура (вырожденный пример - был адрес текстовой строкой а стал чуть ли не целым ФИАС).

Цель - процесс установки обновления может выглядеть так: делаем реплику продакшн -> накатываем обновление -> проводим тестирование -> если все хорошо - повторить на продакшн, остановив ее, иначе отправляем багрепорт разработчикам. Причем все это скриптами автоматически (само собой если для тестирования есть таковые).

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

Тестовая база может быть репликой базы, ей не обязательно быть с самыми свежими данными (хотя если апдейт - фикс бага для данных, которые ввели недавно пользователи - то нужен оперативный бакап).
p.s. Для эффективного создания реплик продакшн базы можно использовать комбинацию master-slave репликации и снапшоты файловой системы (slave базу можно кратковременно приостанавливать, создавать снапшот файловой системы и запускать из него копию базы, первая же slave реплика должна продолжать работать, накапливая изменения с продакшен)

Практически все поставщики sms рассылок предоставляют очень простой api для этого, это один простой запрос http get/post который можно сделать в одну строчку кода.

Бесплатно только кошки родятся, sms стоят денег, и за бесплатно можно либо к кому то присоседиться либо в рекламных каких то целях получить 'скидку' (некоторые поставщики могут давать десяток другой sms бесплатно для теста), видел поставщиков, дающих бесплатные рассылки за добавление своей рекламы в сообщение (для тех кому нужно свои уведомления самому себе слать, но сейчас эту функцию взяли на себя боты телеграм к примеру)

Все так, но.

Разделение по инстансам по факту не сильно увеличивает надежность, ведь они будут однотипные, а значит уязвимость на них будет на всех сразу, если говороть о классических 0day уязвимостях... т.е. что в монолитном варианте что в рапределенном, если ломанут то скорее всего все сразу.

Распределенное решение обладает хорошими плюшками
- облегчается горизонтальная масштабируемость, возможен перенос особо нагружающих пользователей на отдельный сервер 'из коробки'
(монолитный вариант можно так же вынести отдельно, используя мастер-мастер репликацию, иногда дает огромный плюс, но за счет затрат памяти, так как данные копируются все полностью)
- немного уменьшается шанс все сломать из-за ошибки администрирования, особенно если интеграция обновлений будет производиться не сразу на всех, а возможно выделить группу отдельных пользователей для теста на живую, т.е. сломаешь все у тестовой группы а не у всех сразу... но шанс реально мизерный, ошибки по закону подлости всегда коварные и гадкие.

- петька, приборы:
- десять!
- что десять?
- что приборы?

p.s. для красоты и облегчения поддержки кода в будущем, максимально разносите друг от друга все что можно, ваш код, состоящий из одного метода зае... поддерживать другие.
по мне так все что касается интерфейса должно быть исключительно на стороне клиента, все что касается данных и логики - на сервере, так что javascript, ajax/websocket