Starvings, для того, чтобы пользователь получил что-то на текущей странице в ответ на свои действия, надо реализовать реакцию на его действия на js (в виде, допустим, обработчика события onClick на каком-то элементе), php для этого не нужен.
Можно в php вывести что-то типа:
<script>alert('Ляля тополя');</script>
и пользователь при закрытии выскочившего сообщения останется на той же странице. Но на неё он всё равно попадёт с переходом.
Современный способ состоит в том, что обработчик запроса пользователя вызывается javascript через fetch на URL, который представляет API (к примеру, RESTful-сервис) для обработки этого запроса и возвращает машиночитаемый ответ, который js разбирает и использует для обновления html (точнее, DOM) на фронте. Пользователь остаётся в пределах одной страницы, его действия (нажатия на кнопки и ссылки) приводят к вызову javascript-кода, который без перезагрузки страницы дёргает нужные вызовы API. На js пишут так называемый frontend, а на любом другом языке серверный API-интерфейс - так называемый backend. Сайт фактически превращается в так называемый SPA - Single Page Application.
Если хочется изучать именно php и не загружать себе голову излишне раньше времени, я бы посоветовал пока обойтись без js и не париться с перезагрузками страницы. В конце концов, тридцать лет с этим прекрасно люди жили и до сих пор живут. Изучать современные подходы к web всё равно придётся, но это сродни изучение математики, начиная сразу с дифференциальных уравнений, пропустив изучение арифметики.
yotonick, это всё говорит о том, что не надо копировать чужой код без понимания, что именно он делает (да, именно так, каждую строчку до последнего символа надо понимать).
При выполнении запроса надо проверить, что он что-то вернул, и уж потом из его результата что-то брать. Это может вполне даже не быть внештатной ситуацией. Например, пользователь обращается к боту в первый раз, бот обнаруживает, что по пользователю нет данных и явным образом создаёт для него запись в базе, заполняя её значениями по умолчанию. А если запись есть - возвращает данные из неё.
Vano01rus, resolv.conf - это конфигурация штатного функционала ресолвинга имён в IP. Где и как находятся эти IP, какие у них имена и как они разделены на зоны - неважно. Причём в этом файле можно указать только DNS-сервер (nameserver) и не указывать больше ничего - и всё будет работать.
Отдельно можно указать в search до 6 (да, есть лимит) суффиксов, которые будут дописываются к имени при поиске. Например, если в search указано foo bar local ru, то ресолвинг имени yandex будет пытаться перебирать yandex.foo, yandex.bar, yandex.local, yandex.ru по очереди.
Всё это не надо путать с системным hostname, который может быть только один и который к resolv.conf никакого отношения не имеет.
В сухом остатке: можно сделать какие угодно IP на интерфейсах и как угодно обозвать их в DNS (или даже в /etc/hosts, но это будет работать только в пределах этого хоста), для этого в resolv.conf ничего вообще делать не нужно.
TosterIQ, для начала надо вернуть /usr/bin/perl на штатный perl и никогда больше так не делать. В /usr/bin всё должно быть из пакетов и консистентно, если злоупотреблять ковырянием того, что стоит из пакетов, то обновление системы может превратиться в сложный квест (тут советую обратить внимание на rpm -V, который проверяет контрольные суммы файлов в пакете, правда, не уверен, что для symlink он что-то проверит). Устанавливаемый из исходников софт следует или прописывать в PATH, или в /usr/local/bin (как вариант, в $HOME/bin, если это нужно одному пользователю), или, в конце концов, пользоваться полным путём.
В данном случае можно удалить просто весь prefix (только отдельно /usr/bin/perl починить не забыть). Просто многие не указывают его, и используется по умолчанию /usr/local, после чего вычистить софт становится сложнее, так как он вперемешку с другим вручную установленным. Установка в отдельный префикс - это неплохая практика - пусть она и создаёт некоторые свои проблемы (необходимость включать много разных каталогов в PATH, необходимость передавать кастомные ключи сборки при использовании самосборных библиотек итд итп).
kaktak255, гугл регулярно ломает скорость в yt-dlp и в нём регулярно пытаются это починить. Поэтому первый очень важный совет - время от времени его надо обновлять.
bengur2, это в любом случае плохое решение. Всё настраивать надо при сборке образа или в инициализирующем сервис скрипте. Все данные, которые нужны скрипту, хранить в локальном каталоге, который через volume прокидывать внутрь. Тогда перенос будет заключаться в копировании данных и запуске нового контейнера в новом месте.
Собственно, нужно сразу это выучить: docker принципиально предполагает, что контейнер может быть пересоздан в любой момент. Тот же docker-compose пересоздаёт контейнеры при любом изменении параметров безо всяких вопросов. Поэтому проектировать работу с docker надо с учётом этого важного обстоятельства.
Насколько я понимаю, при редактировании нельзя добавить к сообщению обычную клавиатуру. Следует удалить inline-клавиатуру, а потом отправить новое сообщение с обычной.
Все мечтают открывать рекламные и вирусные ссылки так, чтобы пользователь этого не увидел. Разумеется, это нельзя сделать так просто. Это действие квалифицируется как стопроцентно зловредное.
Atlant-19, MediaWiki имеет некоторые настройки в своём конфиге, но в основном идея состоит в том, что там всё управляется через Wiki-движок. В частности, можно кастомизировать движок в целом или персональный пользовательский профиль с помощью специальной страницы, содержащей js (см. https://ru.wikipedia.org/wiki/%D0%92%D0%B8%D0%BA%D... ).
Таким образом, потенциально можно сделать так, что js будет при наличии каких-то элементов на странице с координатами автоматически добавлять div с картой и нужными маркерами в окрестностях необходимой локации.
Точно так же можно сделать, чтобы слайдер добавлялся с помощью js. В том числе он может выгружать список данных из какой-нибудь специальной станицы или даже из категории (возможно, это не самое эффективное решение, но само то, что такое можно делать и даже не одним способом, уже само по себе интересно).
Для Википедии за 20 лет много чего понаписали, что может быть само по себе интересно. Например, wikidata.org с возможностью получения данных через SPARQL-запросы. Вообще, в мире нет другого вики-проекта и вики-движка такого масштаба и такой пользовательской базы.
Другие вики-движки в основном нацелены на другие задачи и другие масштабы. Например, есть свои движки в trac или redmine, они нужны для ведения документации проектов (там заодно есть возможность вести таски, прицеплять репозитории исходного кода и всё такое). Есть xwiki, который бесплатный конкурент confluence и также в своей основной идеологии призван вести документацию в пределах проектов или организаций/структурных подразделений. Есть всякие dokuwiki и ещё много чего. Все они не так заточены под мультиязычность в википедийном стиле через interwiki, так что придётся что-то ещё пилить. Например, самому писать скрипты, которые будут через API доставать данные из разных языковых проектов и проставлять недостающие перекрёстные ссылки. А в Википедии это есть прям из коробки. Но придётся привыкать к специфическому подходу к представлению информации и её редактированию.
Данил Тунев, да, захудалый сайт может сам заморочиться, настроить fail2ban и всё такое. Но многим проще один раз подключить готовый бесплатный сервис и не заморачиваться больше.
GNOME - это НЕ X-сервер, это Desktop Environment, состоящий из большого количества приложений, включая WM (windows manager). Его можно использовать с разными X-серверами, в том числе и с Xvfb. Но поскольку это не для человека, а только для запуска браузера, лучше поставить что-то особенно лёгкое, типа openbox.
ironheaddd, $(...) передаётся в curl как отдельные параметы по пробелам, в итоге в -d передаётся неполный json, а остальное пытается интерпретировать как различные url и на этом ругается (те самые Could not resolve host).
Данил Тунев, дело в том, что фильтровать трафик по простым сигнатурам не особо сложно. Но ещё больше проблем с тем, что можно атаковать целенаправленно конкретных людей/сайты или конкретные категории пользователей. А также промышленный шпионаж и прочие неэтичные игры.
Скажем, приходят к такому сервису дяди в пиджаках и настоятельно (без возможности отказаться) просят предоставлять трафик вон того сайта. Этот риск вполне реален, и про него не надо забывать. Должен сказать, что никто и не забывает. И это, между прочим, очень пилично влияет на отношения доверия. Если CF хоть раз спалится на предоставлении содержимого трафика - их intermediate-сертификат тут же внесут в чёрные списки браузеров. Я не говорю уже о репутационных и финансовых рисках. Для такой крупной компании доверие - это всё.
Вероятно, мухлюют с помощью визуально невидимых юникод-спецсимволов. Я такое использую для невидимой подстановки InstantView в публикации, при этом в тексте есть прямой url, по которому и нажимают пользователи для перехода на сайт. В качестве символа используется word joiner U+2060, но есть и другие.
Можно в php вывести что-то типа:
<script>alert('Ляля тополя');</script>и пользователь при закрытии выскочившего сообщения останется на той же странице. Но на неё он всё равно попадёт с переходом.
Современный способ состоит в том, что обработчик запроса пользователя вызывается javascript через fetch на URL, который представляет API (к примеру, RESTful-сервис) для обработки этого запроса и возвращает машиночитаемый ответ, который js разбирает и использует для обновления html (точнее, DOM) на фронте. Пользователь остаётся в пределах одной страницы, его действия (нажатия на кнопки и ссылки) приводят к вызову javascript-кода, который без перезагрузки страницы дёргает нужные вызовы API. На js пишут так называемый frontend, а на любом другом языке серверный API-интерфейс - так называемый backend. Сайт фактически превращается в так называемый SPA - Single Page Application.
Если хочется изучать именно php и не загружать себе голову излишне раньше времени, я бы посоветовал пока обойтись без js и не париться с перезагрузками страницы. В конце концов, тридцать лет с этим прекрасно люди жили и до сих пор живут. Изучать современные подходы к web всё равно придётся, но это сродни изучение математики, начиная сразу с дифференциальных уравнений, пропустив изучение арифметики.