Kerm, Можете попробовать плясать от глобального массива _context
Вот есть что-то похожее на стэке. Там в первом ответе как раз всё хорошо расписано. https://stackoverflow.com/questions/24697313/how-t...
Но я ещё раз вам рекомендую перенести эту логику в PHP
setuper, Бесконечную загрузку не рекомендую. Http соединения не бесплатные, и если вдруг на ваш сайт повалит народ, то сервер ляжет.
Бесконечную загрузку можно нарисовать при помощи гифки или css-анимаций, а когда с бэкенда в браузер придёт SSE сообщение о том, что админ выбрал вариант, JavaScript перезагрузит страницу, и вуаля!
setuper, А пока администратор проснется и нажмёт на кнопку, посетителю что делать?
Обычный вариант:
Заводите, как обычно, сессии с куками. В куку пишите уникальный id, который присылайте админу в бот. Админ будет тыкать кнопку, а вы в хранилище, где будут храниться ваши сессии, добавляйте информацию, куда этому id идти.
И если увидите, что снова пришла кука с этим id, то туда пользователя и отправляйте.
Лайв-обновление.
Без JavaScript обойтись сложно, но можно использовать HTMX. И использовать так называемые SSE (Server Sent Events). Это вебсокеты для бедных, которые позволяют очень просто слать сообщения на фронтенд. Как их использовать, придётся гуглить.
Мой совет - HTMX и плагин для него с SSE https://htmx.org/extensions/server-sent-events/
Вы хотите, чтобы содержимое сайта менялось прямо "вживую" в браузере у посетителя без перезагрузки страницы или просто, чтобы после перезагрузки изменялась информация?
Просто пофилософствую немного. Может быть, это даст вам какие-то идеи.
Зачем вообще нужно было вводить в обиход нашей прекрасной PHP-экосистемы какие-то сторонние шаблонные языки? Ведь PHP и так прекрасно сочетается с HTML: расставил вопросики со знаками "больше" и "меньше", да и работает.
И второй вопрос: почему у PHP такая плохая репутация? Ведь лично я считаю, что современному PHP ни Python, ни JavaScript даже в подмётки не годятся.
Ответ на оба вопроса: чудовищный говнокод, который стали писать люди, мешая как попало логику и отображение. Исправить баг в этой куче из функций, циклов, ветвлений, перемешанных с развесистым HTML, было просто невозможно. И наш PHP заработал репутацию очень плохого языка.
И вот тогда умные люди решили: а что если мы придумаем для PHP отдельный язык шаблонов, который будет максимально урезан, и программистам придётся не просто отделять HTML от PHP, но и хорошенько подготавливать переменные для этих шаблонов, ведь даже несложную логику на этом языке шаблонов писать очень больно. Это решение (и некоторые другие) настолько улучшило PHP код, что язык ожил, стал развиваться и снова стал нравиться людям, которые постоянно его улучшают.
Так вот... Может быть, вам подготовить все переменные для twig заранее? Чтобы не было вот этой боли?
Этот комментарий просто "на подумать"...
Генерируете нужные вам размеры с названиями и заливаете их всех в CDN
123456-100x100.jpg
123456-200x200.jpg
....
123456-thumb.jpg
123456-big.jpg
123456.jpg // оригинал
К сожалению, не знаю, как в мобильной разработке определяется, когда какое изображение показать, но просто генерируете эти названия точно так же в зависимости от необходимости, и вставляете их в сгенерированную с этим названием ссылку CDN.
Никого не слушайте, просто берите WordPress. У него просто подавляющее превосходство в распространенности, а это означает подавляющее превосходство в количестве разработчиков на любой бюджет
JastaFly, Вот вы тут пишете, что всё работало, но вы проявили невнимательность в preg_replace_callback.
Это и есть проблема, это и будет у вас всегда проблемой, если будете парсить HTML регулярками. Потому что это всё трудно анализировать и дебажить. Жаль, что будете учиться на своих ошибках, а не на чужих. Я когда-то, много лет назад тоже был такой парсильщик HTML регулярками, когда их изучил. Уйму времени потратил совершенно бестолково.
А насчёт того, что я вам посоветовал регулярку после обработки парсером, так это потому, что это как раз и место для регулярок: одна типовая строчка. Тут не запутаешься.
Как я понимаю, вы разрабатываете что-то типа платных плагинов или тем для опенсорсных CMS, потому что если вы разрабатываете сервис полностью сами, то мой совет был бы вообще сменить язык программирования и распространять бинарники вместо кода в текущей модели бизнеса, либо сесть всем вместе и подумать, что вам изменить, чтобы не применять подобные архаичные методы. Сейчас мало кто таким пользуется, и советов хороших по выбору того или иного, вы вряд ли получите.
Если выбора нет, то простые обфускаторы кода вам не помогут, потому что вернуть их в человекочитаемый вид проще простого (особенно в наш век GPT), и не так дорого. Поэтому, надо выбирать то, что работает в связке с сервером, типа ioncube. И если вы уже собрали список, то просто попробуйте сами все варианты и выберите что-то, что будет максимально-комфортным для вас.
Полностью с вами согласен, но всё же у фрилансеров, особенно начинающих, до сих пор бывает так, что нет выбора, и им приходится соглашаться на требования некоторых нерадивых заказчиков. Они берут в том числе и такие заказы. Обиднее всего, когда работа была проделана очень большая, а клиент, казавшийся адекватным, вдруг отказывается платить совсем.
У меня лично лет 10 или даже больше назад был случай, когда сдавал человеку подряд несколько проектов, он прекрасно платил, и его просьба залить код на прод до оплаты вообще не вызвала никаких подозрений. И тут связь оборвалась, все доступы были отключены, меня просто игнорировали. На его голову он забыл закрыть один из FTP доступов. И я просто зашифровал одним из подобных обфускаторов весь код, который сам лично написал. Магическим образом моя работа была через неделю оплачена, а я предоставил незашифрованный код...
