rPman

Открывамем гугл, пишем github browser mobile detector
получаем ссылку на почти сотню проектов, отсортированных по популярности, первый какраз на php

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

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

p.s. вполне возможно что сейчас лучше/удобнее формировать .m3u8 плейлист, javascript там продвинутый у html video, но если что его можно формировать и прописывать с помощью data uri.

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

Выбрав SSI ты заранее создал себе проблемы.
Собирать страницу из кусочков можно на самом php, прямо в твоем process.php (именно так и делают), а с помощью mod_rewrite веб сервера скрывают .php от пользователя, оставив /process

Так же совершенно нормально (с оговорками про поисковые системы, роботы еще не очень хорошо читают такие страницы но все решаемо) формировать страницу не на сервере а на клиенте, с помощью javascript (такой подход активно используется в SPA веб приложениях), в этом и похожих случаях необходимые переменные передаются с сервера на клиент с помощью технологии ajax (на основе fetch или XMLHttpRequest, сам ajax реализован в популярном jquery) а еще лучше с помощью websocket (но нужно на сервере уже бакэнд с его поддержкой), ведь это позволит не только клиенту запрашивать данные но и серверу оперативно передавать данные клиенту по своему желанию а не когда спросят.

тебе так сложно нажать правую кнопку в инспекторе на нужной ветке и выбрать copy as css selector?
не всегда оно красивое но браузер старается
#processor > option:nth-child(1)

по теме, воспользуйся css selector по значению атрибута
#processor > option[value="6398"]

p.s. тебе точно нужно выбирать по значению цены? может правильнее использовать querySelectorAll и перебирать каждое значение, проверять по условию и действовать?

функция date умеет только англоязычные названия (формат 'F'). Для русских подменяй сам, заведи константу массив (нулевой элемент пустой, так как нумерация месяцев с нуля) типа $month_names=['','Январь','Февраль',... и для вывода пользуйся $month_names[$mon]

Формат в date для месяца бери 'n', он выдаст номер без дополнительного символа 0 в начале (если оставишь 'm' то в массиве имен не будут найдены значения по ключу '01'...)

p.s. есть strftime, оно умеет разные языки, но русский не умеет (хотя в системе все прописано и настроено)

console.log(xhr.status) перед if-ом, проверь, возможно у тебя твой бакэнд возвращает не 200
а еще в отладочной консоли и networks браузера смотри, если ошибки там про это будет написано

Есть косвенное решение - разрешить в браузере сохранять загрузки автоматически без запроса места сохранения (на сколько я знаю это поведение по умолчанию) и из скрипта сформировать файл через File, Blob или MediaSource, создать для него ссылку с помощью createObjectURL (на сколько я помню это будет data uri строчка) и кликнуть по ней.

var file=new Blob([JSON.stringify(obj, null, 2)], {  type: "application/json"});
var url=URL.createObjectURL(file);
var a = document.getElementById("a"); // где то на странице невидимая ссылка
a.href = URL.createObjectURL(file);
a.download = 'myfilename.json';

Как вариант строчку сделать самому и отправить его прямо в location, что то типа location.href='data:text/plain;charset=utf-8,test').

Твое python приложение пусть ожидает файл в каталоге для загрузок, указанном в настройках браузера. Будь готов, что браузер добавить ' (xxx)' к имени файла, если такой же там уже есть.

Я примерно таким образом добавленным через консоль (или расширением типа greasemonkey) скриптом кликал и собирал данные в веб приложении, после отправлял их на сохранение в виде csv-шника, а затем собрал кучу сохраненных файлов уже десктопным приложением.

Какое то окошко выскочит все равно, либо окно скриншота либо запрос подтверждения сохранения файла, штатный браузер не даст сохранять файлы без спроса.

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

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

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

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

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

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

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

{$txt}

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

так же настоятельно рекомендую, прежде чем делать приложение, протестировать ссылки вручную через curl, будет видно и ответ, а с ключом -v подробности и заголовки ответа.

fopen не самый лучший способ коммуникации по сети, проще было бы file_get_contents использовать, и у него есть context, который позволяет много что настроить в запросе) но лучше пользоваться встроенный curl_xxx

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

Сайт должен представлять из себя программу удаленного управления, а реальный сайт запускаться на кастомном браузере (без интерфейса, пишется в 10 строчек на любом языке программирования на основе готовых контролов браузерных webview - chromium/firefox/webkit).

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

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

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

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

В общем случае - никак

Но можно сделать этот процесс на столько сложным, что смысла в этом уже никакого не будет. С помощью обфускации кода и использовании алгоритмов шифрования данных, передаваемых в браузер (не про https а когда данные, загружаемые браузером и передаваемые в скрипты/данные - зашифрованы). А чтобы конечный скрипт нельзя было вытащить через модификацию браузера (например логировать eval) то можно саму виртуальную машину, исполняющую скрипты, реализовать на js (wasm).

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

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

p.s. есть еще гомоморфное шифрование, когда есть необходимость совершать какие то операции над данными, которые зашифрованы, без их расшифровки. Особо его применить в данной задаче сложно но бывают случаи когда можно выкрутиться. Если что это решение очень сложное (читай дорогое) в реализации, готовых решений нет (по крайней мере для браузера и javascript) а еще оно потребляет процессорные ресурсы.

Правильно - websocket

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

Требуется на сервере установить (реализовать в коде) websocket server, благодаря готовым библиотекам это очень просто, гуглить к примеру ReactPHP websocket (реакт - асинхронный фреймворк, добавляет асинхронные фичи, за которые полюбили nodejs), на нем вообще можно реализовать полноценный веб сервер (но nginx все равно рекомендуется ставить на выходе в мир как прокси) которые и обычные http rest запросы примет и websocket соединения подержит, да еще и раз в 10000 быстрее будет (я про сравнение типовых подходов без особых оптимизаций и кешировании), ведь приложение в этом случае не закрывается на каждый запрос а значит многое можно держать в памяти как обычные переменные (а не 100500 прослоек вида мемкеш)

p.s. есть еще устаревшая long pooling технология, когда вместо websocket открывается обычный http rest запрос, но на сервере он не закрывается сразу, периодически выдавая в поток допустим 1 символ пробела (крутя в цикле банальный sleep и проверку базы данных) чтобы по таймауту не закрылся, а по появлению на сервере нужных данных, отправлять их как обычно тем же json-ом. Клиент же сразу как этот запрос завершается должен тут же его снова отправить. Этот подход не потребует что то менять на сервере но считается быдлокодом.