rPman

{$txt}

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

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

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

у тебя на стилях твоих сервер выдает хеадер

cache-control max-age=31536000
expires Mon, 25 Dec 2023 17:55:13 GMT

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

это классическая проблема и решается в простом виде добавлением к имени файла какого то идентификатора, определяемого версией файла (например дата или хеш файла) например так main.css?i=123123

p.s. лучше меняй сразу имя файла на main.123123.css, так ошибки легче будет отловить (если где то забудешь изменить ссылку)

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

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

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

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

Советую изучать с низов, самостоятельно, чтобы было понимание каждого шага, всего что происходит.
* операционные системы, процессор и многопоточность, сети,...
глубоко изучать это не требуется но базовые понимания нужны чтобы не получать медленное приложение только потому что не знал что каждый твой запрос в tcp это 'туда-сюда', и это медленно (десятки миллисекунд), что одновременно два человека пытающиеся что то изменить на сайте нужно разруливать чтобы не было конфликтов и т.п.
* бакэнд и фронтэнд
буквально что значит запрос и генерация ответа, какие бывают способы организации этого бакэнда (http rest и к примеру websocket), не понимание разницы между бакэндом и фронтэндом у новичков рождает абсурдные вопросы как из javascript изменить переменную php (и наоборот)... в чем разница между генерацией страницы на сервере и в браузере.
* html, css,..
верстка и дизайн, отдельный мир браузерных стандартов, исторических наслоений,. когда стоит применять фреймы, почему шрифты по разному выглядят, разные устройства и размеры экранов, разные способы взаимодействия (сенсорный экран, мышь, клавиатура)...
* базы данных
еще более огромный мир атомарных транзакций, индексов, нормальных форм и прочего
* девопс
без умения выбрать инструмент, настроить тулчейны, среду разработки, среду исполнения (веб сервер), настроить бакапы и прочее пытаться что то разрабатывать это как в слепую гулять по лесу, будешь постоянно на ветки натыкаться
...
это я еще про системную аналитику не сказал, обычно прежде чем что то создавать, нужно продумать как это все делать, что такое технический долг и т.п., а еще есть тестирование, обслуживание, работа с отказами (сервер сдох, база упала, как все восстановить), обновление на живую и прочие веселья

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

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

работает локально, даже из файла file://

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

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

браузеры правильно защищают от доступа к локальным ресурсам, запрещая смешивать ресурсы из разных протоколов https/http/file в любом порядке (например если ты открываешь страницу с веб сервера по https то тебе будут запрещены ajax запросы по http но разрешены вставки картинок, и все будет запрещено по file)

пропиши каталог с файлами в веб сервере как статика и открывай нормально по http

докину варианты, в linux есть проект fuse, позволяет монтировать файловые системы, описываемые простой библиотекой, работающей как обычное приложение в userspace, на основе его сделана поддержка всяких экзотических ситуаций, в т.ч. работа по ftp - ftpfs (идет штатно с любым линукс), так же есть sshfs для доступа по ssh, avfs для архивов (сюда же fuse-zip и archivemount) или экзотический winregfs для чтения файлов реестра windows как файлы и т.п. десятки библиотек идут по дефолту в репозитории.

монтируешь в каталог без root и пользуешься как локальными файлами из любых программ

Отвечу максимально полно

Чтобы скрипт php что то 'получил', он должен быть как минимум запущен, подавляющее большинство стратегий создания приложений на php это когда клиент (браузер) либо чистый html либо javascript делает запрос на сервер, а сервер запускает на короткое время php скрипт чтобы тот вернул ответ (готовый html или данные в каком то виде, например json чтобы javascript обработал)

Общение между браузером и сервером происходит по http короткими запросами вопрос-ответ, поэтому фраза 'установить переменную' немного некорректна в этом случае, ведь установив переменную в результате запроса, таковой она будет только тот короткий момент, пока этот запрос обрабатывается (например все что идет в http запросе как GET или POST параметры, веб сервер автоматически прописывает в глобальные переменные $_GET и $_POST соответственно, бери и читай). Для отправки запросов из браузера на сервер есть готовые библиотеки, гуглить ajax (на чистом javascript без библиотек для этого можно использовать XMLHttpRequest)

Поэтому есть способ передачи данных через заголовки запроса, с помощью cookies, браузер устанавливает куки, которые автоматически в дальнейшем добавляются к любому запросу с данного домена на сервер. На сервере в php доступ к ним можно получить из переменной $_COOKIE. Так же есть способ установить куки со стороны сервера. С точки зрения эффективности это не самый лучший способ, так как данные получаются не сохраняются где то на сервере, а транслируются повторно с каждым запросом, поэтому большие объемы хранить там не рекомендуется.

Существует подход, когда php приложение не короткоживущий скрипт а сам веб сервер, обработка запросов, чтение get/post параметров, куки и прочее, в этом случае обрабатывает это приложение (есть библиотеки, например асинхронный php react), но зато, так как приложение не завершает свою работу после запроса, прочитав переменную из запроса ее можно сохранить в памяти приложения. Этот подход на порядок ускоряет работу приложений по сравнению с классическим http-rest подходом (ведь скриптам не нужно на каждый запрос восстанавливать состояние серверного приложения, загружая нужные данные откуда-то, например из базы данных) т.е. из коробки более быстрый но сложнее к масштабированию.

В качестве бонуса у этого подхода появляется удобная возможность использовать websocket, когда запросы отправляются не в виде отдельных а как пакет данных внутри уже открытого соединения (если что веб серверы и браузеры поддерживают и для типичного http rest незакрываемые соединения, но они заголовки так или иначе передаются, занимая время и ресурсы), и не только клиентское приложение сможет отправлять запросы от браузера на сервер но и сервер сможет слать сообщения клиенту