Php как работает

Язык программирования PHP: как устроен и работает PHP?

Язык программирования PHP это скриптовый язык программирования для создания веб-сайтов. Язык программирования PHP является одним из лидеров среди языков для создания web-сайтов, потому что он изначально был «заточен» под их написание. Большинство популярных CMS таких как Joomla, WordPress, Drupal написаны на этом языке.

PHP является объектно-ориентированным языком наподобие C++, Java, C#. Он имеет большое количество различных встроенных библиотек что существенно облегчает и ускоряет написание web-приложений: библиотека для работы с текстовыми файлами, работы с изображениями популярных форматов (кроп, масштабирование изображения, вставка одного изображения в другое и др.), библиотеки для работы с xml и html (Работа с DOM), работы с http (удаленный запрос к серверу, получение ответа с содержимым от сервера) CURL, библиотеки для работы с базами данных (mysql, PDO), криптографические библиотеки, библиотеки для работы с файловой системой, обработка аудио форматов.

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

Как устроен и работает PHP?

PHP работает на базе архитектуры «клиент-сервер», то есть PHP скрипты как и сам интерпретатор PHP находятся на специальном компьютере — сервере. Интерпретатор PHP состоит из ядра и подключаемых динамических библиотек. Интерпретатор PHP имеет специальный конфигурационный файл — php.ini , содержащий множество настроек, изменение которых влияет на поведение интерпретатора.

Как работает PHP? За работу PHP интерпретатора отвечает web-сервер (например Apache), который обычно устанавливается вместе с PHP интерпретатором и какой нибудь СУБД в связке (например в пакетах LAMP или MAMP). При получении запроса c URL страницей сайта от браузера (клиента) web-сервер находит нужный скрипт у себя на жестком диске и отдает команду php-интерпретатору выполнить этот скрипт.

Разберем этот процесс более подробно. Например, вы хотите зайти на сайт yandex.ru:

1. Сначала вы набираете в адресной строке вашего браузера адрес сайта

2. После того как вы набрали адрес сайта и нажали Enter, клиент (в нашем случае это браузер) посылает запрос серверу (то есть компьютеру, на котором размещен сайт) через протокол http. Грубо говоря, браузер говорит серверу: я мозилла фаерфокс (например), дай мне информацию по такому то URL адресу (в нашем случае URL адрес это http://yandex.ru).

3. Сервер обрабатывает запрос клиента, и находит нужный ресурс (скрипт, картинку либо еще какой нибудь файл) у себя на жестком диске ориентируясь на полученный URL адрес. Если файл либо директория по заданному URL адресу на сервере не будут найдены, то сервер отправит клиенту (браузеру) ответ с определенным кодом 404 — «не найдено». При этом в браузере отобразится соответствующее сообщение: «Страница не найдена». Если же сервер найдет нужный скрипт по заданному URL адресу, то он поручит интерпретатору PHP выполнить этот скрипт, а результат выполнения (если он есть) сервер «отдаст» браузеру по протоколу http в виде html кода. Так же помимо самой информации web-сервер передает браузеру различные http заголовки. Но об этом уже в других статьях

Современный PHP без фреймворков

У меня есть для вас непростое задание. Когда в следующий раз начнёте новый проект, постарайтесь обойтись без PHP-фреймворка. Я не собираюсь перечислять недостатки фреймворков, и это не проявление синдрома неприятия чужой разработки: в этом руководстве мы будем использовать пакеты, написанные разработчиками нескольких фреймворков. Я всецело уважаю инновации в этой сфере.

Но эта статья не о них. Она о вас. О возможности стать лучше как разработчик.

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

Возможно, ваша следующая работа не позволит вам насладиться запуском нового проекта без фреймворка. Многие важные, критические для бизнеса PHP-задачи подразумевают использование уже существующих приложений. И неважно, будет это приложение, построенное на современном фреймворке вроде Laravel или Symfony, на одной из старых платформ вроде CodeIgniter или FuelPHP — либо это удручающе широко распространённое легаси PHP-приложение с «include-oriented архитектурой»: если сейчас вы будете разрабатывать без фреймворка, то окажетесь лучше подготовлены к любому будущему PHP-проекту.

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

Но сегодня благодаря стараниям PHP-FIG в сфере автозагрузки и взаимной совместимости вы можете разрабатывать без фреймворка, не создавая его попутно. Существует множество замечательных, взаимно совместимых пакетов, написанных многочисленными разработчиками. И собрать их в единую систему гораздо проще, чем вы думаете!

Как работает PHP?

Прежде всего важно понять, как PHP-приложения взаимодействуют с внешним миром.

PHP исполняет серверные приложения в цикле запрос/ответ. Всё взаимодействие с приложением — из браузера, командной строки или REST API — приходит в него в качестве запросов. При получении запроса приложение загружается, обрабатывает запрос и генерирует ответ, который передаётся обратно клиенту, а приложение закрывается. И так происходит при каждом обращении.

Контроллер запросов

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

Давайте воспользуемся классическим примером с Hello, world!, обслуживаемым встроенным в PHP веб-сервером, чтобы проверить, всё ли настроено корректно. Если вы этого ещё не сделали, то удостоверьтесь, что в среде установлен PHP 7.1 или выше.

Создадим директорию проекта, в ней сделаем вложенную директорию public , а внутри неё — файл index.php с таким кодом:

Обратите внимание, здесь мы объявляем строгую типизацию — это нужно делать в начале каждого PHP-файла вашего приложения, — потому что подсказки типов (type hinting) важны для отладки и ясного понимания теми, кто будет заниматься кодом после вас.

Далее с помощью инструмента командной строки (вроде Terminal на MacOS) перейдём в директорию проекта и запустим встроенный в PHP веб-сервер.

Теперь откроем в браузере адрес http://localhost:8080/. Отображается Hello, world! без ошибок?

Отлично. Переходим к следующему шагу!

Автозагрузка и сторонние пакеты

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

Выход — автозагрузка. Это означает, что, когда вашему приложению нужно использовать какой-то класс, PHP знает, где его найти, и автоматически загружает в момент вызова. Эта возможность существует со времён PHP 5, но стала активно применяться только с появлением PSR-0 (стандарта автозагрузки, сегодня заменён PSR-4).

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

Проверьте, что у вас установлен Composer. Затем настройте его для своего проекта.

После этого пройдите через интерактивное руководство по генерированию конфигурационного файла composer.json . Затем откройте его в редакторе и добавьте поле autoload , чтобы получилось так, как показано ниже (тогда автозагрузчик будет знать, где искать ваши классы).

Теперь установите для этого проекта Composer, которые подтянет все зависимости (если они уже есть) и настроит для нас автозагрузчик.

Обновите public/index.php для запуска автозагрузчика. В идеале это одно из нескольких выражений include, которые вы используете в приложении.

Если перезагрузить приложение в браузере, вы не увидите никакой разницы. Однако автозагрузчик работает, просто он не делает ничего тяжёлого. Давайте перенесём пример с Hello, world! в автоматически загружаемый класс, чтобы проверить, как всё работает.

В корне проекта создадим папку src и вставим в неё файл HelloWorld.php с таким кодом:

Теперь в public/index.php замените выражение echo вызовом метода announce в классе HelloWorld .

Перезагрузите приложение в браузере и увидите новое сообщение!

Что такое внедрение зависимостей?

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

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

Но это не лучшее решение. На чуждый метод возлагается ответственность за создание объекта нового подключения к БД, получения учётных данных и обработки любых проблем в случае сбоя подключения. В результате в приложении дублируется масса кода. А если вы попытаетесь прогнать этот класс через модульное тестирование, то не сможете. Класс тесно взаимосвязан со средой приложения и базой данных.

Давайте с самого начала не будем усложнять работу с тем, что требуется классу. Просто в первую очередь потребуем, чтобы объект PDO был внедрён в класс.

Получилось гораздо чище и проще для понимания, меньше вероятность ошибок. Благодаря подсказке типов и внедрению зависимостей метод объявляет именно то, что ему нужно для выполнения задачи, и получает необходимое без вызова из себя внешней зависимости. А когда речь пойдёт о модульном тестировании, мы окажемся готовы к моделированию подключения к БД и спокойно пройдём тест.

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

Мы воспользуемся самым популярным DI-контейнером для PHP с изобретательным названием PHP-DI. (Надо отметить, что в его документации внедрение зависимостей описано иначе, и кому-то так будет понятнее.)

Контейнер внедрения зависимостей

Поскольку мы настроили Composer, установка PHP-DI пройдёт практически безболезненно. Для этого снова обратимся к командной строке:

Обновите public/index.php для конфигурирования и сборки контейнера.

Ничего особенного пока не произошло. Это лишь простой пример, где всё необходимое помещено в один файл для удобства наблюдения.

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

Заметка на полях: автоматическое внедрение зависимостей может быть полезной фичей в начале создания приложения, но в дальнейшем оно усложняет сопровождение, поскольку зависимости остаются относительно скрытыми. К тому же возможно, что через несколько лет другой разработчик подключит какую-нибудь библиотеку, и в результате несколько библиотек будут реализовывать один интерфейс. Это сломает автоматическое внедрение зависимостей и приведёт к непредсказуемому потоку багов. Разработчик, внёсший изменение, может их вообще не заметить.

Давайте ещё больше всё упростим, импортировав пространства имён там, где это возможно.

Пока что выглядит всё так, словно мы устроили суматоху ради выполнения того, что уже делали раньше.

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

Middleware

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

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

Варианты использования промежуточных слоев:

Отладка проблем при разработке.
Постепенная обработка исключений в production.
Ограничение частоты входящих запросов.
Ответы на запросы неподдерживаемых медиатипов.
Обработка CORS.
Маршрутизация запросов в соответствующие обрабатывающие классы.

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

Мы воспользуемся промежуточным слоем для последнего сценария: маршрутизации.

Маршрутизация

Маршрутизатор применяет информацию из запроса, чтобы понять, какой класс должен его обработать (например, URI /products/purple-dress/medium должен быть обработан с помощью класса ProductDetails::class с передаваемыми в качестве аргументов purple-dress и medium ).

Наше приложение будет использовать популярный маршрутизатор FastRoute через реализацию промежуточного слоя, совместимого с PSR-15.

Диспетчер middleware

Чтобы наше приложение стало работать с каким-либо промежуточным слоем, нам понадобится диспетчер.

PSR-15 — это стандарт, определяющий интерфейсы для middleware и диспетчеров (в спецификации они называются «обработчики запросов»), обеспечивающий взаимосовместимость широкого спектра решений. Нам лишь нужно выбрать диспетчер, совместимый с PSR-15, и он будет работать с любым совместимым middleware.

В качестве диспетчера установим Relay.

А поскольку спецификация PSR-15 подразумевает, чтобы реализация промежуточного слоя передавала HTTP-сообщения, совместимые с PSR-7, мы воспользуемся Zend Diactoros.

Подготовим Relay к приёму промежуточных слоев.

В строке 16 мы с помощью ServerRequestFactory::fromGlobals() будем собирать всю информацию, необходимую для создания нового запроса и передачи его Relay . Здесь запрос попадает в стек промежуточных слоев.

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

А теперь определим маршрут для класса обработчика Hello, world. Здесь мы воспользуемся маршрутом /hello , чтобы продемонстрировать возможность использования маршрута, отличающегося от базового URI.

Чтобы всё заработало, нужно обновить HelloWorld , сделав его вызываемым классом, то есть чтобы этот класс можно было вызвать как функцию.

Обратите внимание на добавленный exit; в магическом методе __invoke() . Скоро вы поймёте, к чему это.

Теперь откройте http://localhost:8080/hello и наслаждайтесь своим успехом!

Клей, который всё скрепляет вместе

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

Так зачем он нужен?

А что, если — как это почти всегда бывает в реальных приложениях — у класса HelloWorld есть зависимость?

Давайте её добавим и посмотрим, что произойдёт.

Перезагрузим браузер, и.

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

Давайте определим зависимость в контейнере и передадим его в RequestHandler для разрешения.

Вуаля! При перезагрузке браузера вы должны увидеть Hello, bar world!.

Правильная отправка ответов

Помните, я упомянул о выражении exit в HelloWorld ?

Это простой способ удостовериться, что мы получили простой ответ, но всё же это не лучший способ отправки выходных данных в браузер. Такой грубый подход заставляет HelloWorld делать лишнюю работу по отдаче отчетов — а этим должен заниматься другой класс, — что слишком усложняет отправку заголовков и кодов статуса, а также приводит к закрытию приложения, не давая шансов запуститься промежуточному ПО, идущему после HelloWorld .

Помните, что каждый промежуточный слой имеет возможность модифицировать запрос по пути в приложение, а также (в обратном порядке) модифицировать ответ по пути из приложения. В дополнение к стандартному интерфейсу для Request PSR-7 определяет структуру ещё одного HTTP-сообщения, которое будет нам полезно на обратной ветке цикла: Response . Если хотите, можете почитать подробнее о HTTP-сообщениях и о том, чем хороши стандарты PSR-7 Request и Response.

Обновим HelloWorld для возвращения Response .

Обновим определение контейнера, чтоб HelloWorld предоставлялся со свежим объектом Response .

Если мы сейчас обновим страницу, то получим пустой экран. Приложение возвращает из диспетчера промежуточных слоев правильный объект Response , а потом… что?

Просто ничего с ним не делает.

Нам нужен ещё один инструмент: эмиттер. Он находится между приложением и веб-сервером (Apache, nginx и т. д.) и отправляет ваш ответ клиенту, сгенерировавшему запрос. Эмиттер просто берёт объект Response и преобразует в инструкции, доступные для понимания серверным API.

Хорошие новости! Пакет Zend Diactoros , который мы уже используем для управления запросами, включает в себя эмиттер для ответов PSR-7.

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

Обновим public/index.php для получения Response от диспетчера и передачи в эмиттер.

Перезагрузим страницу — мы снова в деле! Пришло время для более надёжной обработки ответов.

В строке 15 заканчивается цикл запрос/ответ и вступает в работу веб-сервер.

Завершение

С помощью 44 строк кода и нескольких широко используемых, тщательно протестированных, надёжных, взаимодействующих друг с другом компонентов мы реализовали программу bootstrap современного PHP-приложения. Он совместим со стандартами PSR-4, PSR-7, PSR-11 и PSR-15, поэтому вам доступен широкий спектр реализаций HTTP-сообщений, DI-контейнеров, middleware и диспетчеров.

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

Использованное в статье приложение лежит в репозитории, можете свободно форкать и скачивать.

Если воспользуетесь этим кодом в production , то, вероятно, вам понадобится вынести маршруты и определения контейнера в отдельные файлы, чтобы легче было сопровождать их по мере усложнения проекта. Также рекомендую реализовать EmitterStack для «умной» обработки скачиваний файлов и прочих больших ответов.

Самые основы. Как работает PHP.

Отличие веб-приложения от обычной программы
Начиная писать программы для веба, многие начинающие программисты сталкиваются с такой ошибкой. Они рассматривают систему браузер-сервер, как обычное приложение. Интерактивное. Нажал кнопку — система среагировала. Провел мышкой — среагировала. Вся информация, которая доступна клиенту — доступна и программе, программа все время находится в памяти.
Так вот, в веб-программировании это не так!.
В момент, когда пользователь видит перед собой страницу и начинает совершать какие-то действия с ней, PHP уже завершил работу! И пользователь взаимодействует не с PHP скриптом, а со своей страницей HTML, которую он получил в браузер. Результатом работы скрипта на PHP в большинстве случаев является обычный текст. Текст HTML страницы. Которая отдается браузеру и показывается им, как обычный HTML. Вы сами можете в этом убедиться, написав в скрипте
<? echo «Привет, <b>Вася!</b>»; ?>;
А потом просмотрев в браузере исходный текст полученной страницы. Никаких тегов PHP там нет! Только
Привет, <b>Вася!</b>
Потому, что PHP исполняется на сервере!

Сервер и браузер общаются, посылая друг другу запросы по особому протоколу — HTTP. Соединение может инициировать только браузер. Он посылает серверу запрос — показать такой-то файл. Сервер клиенту файл посылает.
Только так и происходит. Клиент запросил — сервер отдал. И забыл сразу о клиенте. Отсюда становится понятным ответ на вопрос, можно ли точно узнать, сколько юзеров сечас на сайте. Нельзя. потому, что «на сайте» нету ни одного. Они соединяются, запрашивают страницу, и отсоединяются. Не имеют постоянного cоединения с сервером, как, например, игроки в Кваку. Узнать можно только примерно, записывая время каждого соединения и выбирая записи за определенный промежуток времени.

Так же, отсюда становится ясно, что сервер может узнать о клиенте очень мало. Только то, что клиент пришлет в HTTP-запросе. Разрешения экрана там нет 😉
Все, что сервер может знать о клиенте, можно посмотреть командой phpinfo()

Пример общения браузера с сервером:
Пользователь нажимает на ссылку, браузер посылает запрос серверу и ждет ответа:
Браузер -> PHP
PHP выполняет скрипт, отдает результат в браузер и завершает работу:
PHP -> браузер
Браузер отображает страницу, «просматривая» её на предмет ссылок, которые надо запросить у сервера (теги <img src>, <script src> и так далее) и посылает соответствующие запросы. Их можно увидеть, просматривая обмен заголовками, о чем речь будет чуть ниже:
Браузер -> сервер, Браузер -> сервер, Браузер -> сервер.
Пользователь заполняет форму и нажимает на кнопку:
Браузер -> PHP
PHP обрабатывает форму, записывает данные в базу и посылает браузеру заголовок
Location:
PHP -> браузер
Браузер, получив этот заголовок, запрашивает указанную страницу
Браузер -> PHP
PHP выполняет ее. и так далее.

Как работает РНР, где он выполняется?
РНР выполняется на сервере. Браузер посылает серверу запрос на страницу с php кодом. Сервер отдает эту страницу на исполнение интерпретатору PHP, интерпретатор генерирует HTML код, отдает серверу, а сервер посылает клиенту. Никакого РНР кода в браузер не попадает (это важно! Это значит, что увидеть исходный код PHP скрипта невозможно!). Единственный способ отправить что-то скрипту — это кликнуть по ссылке или нажать на кнопку в форме. Так, чтобы РНР обрабатывал какие-то действия пользователя в браузере — невозможно. РНР остался на сервере, ждать новых запросов с данными для обработки. PHP, но не скрипт! Скрипт, который выполнялся, отдавая пользователю страницу, завершил работу. Все данные, которые были в нем — пропали. Именно поэтому, если какая-то переменная нужна при последующих вызовах скрипта, ее надо этому скрипту передать снова.

Очень качественная и подробная статья об основах веб-программирования находится на сайте PHPWIKI.RU. Обязательно прочитайте её.

Как передать переменную из PHP в JavaScript и обратно?
Начнем с того, что никакую переменную передать, конечно же, невозможно. Поскольку переменная — это часть программы. И из одной в другую передать её нельзя. Передать можно только значение переменной. Т.е. текст. То есть, различия между «передачей переменной в яваскрипт» и формированием html таблицы НЕТ НИКАКОГО!
Отсюда вывод — «Передать переменную» в Javascript очень легко. Особенно, повторюсь, если учесть, что никакой «передачи» не происходит. PHP просто напросто генерирует яваскрипт точно так же, как и всю остальную страницу, вместе со всеми переменными.
Точно так же, как вы выводите в браузер строку «Hello World, это Вася Пупкин!», выводится и любой яваскрипт, со всеми своими переменными.
Единственное условие — вы должны представлять себе тот яваскрипт, который хотите получить.
К примеру в PHP есть переменная $name=»Вася» , значение которой надо передать в яваскрипт, чтобы получить
<script>name=»Вася»;</script>
Мы просто пишем
<?
$name=»Вася»;
?>
<script>name=»<? echo $name; ?>»</script>
То есть, фактически, мы просто сформировали нашим PHP скриптом некий текст, который выглядит, как нужный нам код на яваскрипте. Или, с другой стороны, мы писали свой яваскрипт, в нужных местах вставляя вывод переменных из PHP.
Чтобы не сойти с ума от разнообразных кавычек, настоятельно рекомендуется яваскрипт выводить не весь с помощью echo, а именно так, как написано здесь — закрыв тег PHP и открывая их только там, где нужно вывести переменную.

Как передать переменную из яваскрипта в PHP?
Точно так же, как и любые другие данные — послав запрос на сервер.
Но надо четко понимать, что во время выполнения php скрипта получить что-либо из яваскрипта, разумеется, невозможно. Передать можно будет только при следующем запросе. И обрабатывать его будет уже другой PHP скрипт.
Если надо по событию onClick обратиться к базе данных, то следует помнить, что она находится на сервере. То есть, надо запрашивать сервер, который запустит PHP скрипт, который обратится к базе, получит от неё ответ и передаст его в браузер.

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

Способы общения браузера с сервером.
Способов, предоставляемых протоколом HTTP, немного. Это важная информация. Никаких других способов нет. На практике используются два:
GET — это когда данные передаются в адресной строке, например, когда пользователь жмет ссылку.
POST — когда он нажимает кнопку в форме.
Сформировали страницу со ссылкой или с формой методом GET — запрос придет GET-ом. Сформировали с формой, в которой указан метод POST — придет POST-ом.
Определить, какой способ следует применять, очень просто. Если форма служит для запроса некой информации, например — при поиске, то ее следует отправлять методом GET. Чтобы можно было обновлять страницу, можно было поставить закладку и или послать ссылку другу.
Если же в результате отправки формы данные записываются или изменяются на сервере, то следует их отправлять методом POST, причем обязательно после обработки формы надо перенаправить браузер методом GET. Так же, POST может понадобиться, если на сервер надо передать большой объём данных (у GET он сильно ограничен), а так же, если не следует «светить» передаваемые данные в адресной строке (при вводе логина и пароля, например). Но в любом случае, после обработки POST надо всегда перенаправлять браузер на какую-нибудь страницу, пусть ту же самую, но уже без данных формы, чтобы при обновлении страницы они не записывались повторно. Например:
header(«Location: http://».$_SERVER[‘HTTP_HOST’].$_SERVER[‘REQUEST_URI’]);
exit;

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

Полезная информация может содержаться в различных НТТР заголовках.
Cookie — если сервер поставил куку, и она не устарела, то браузер отсылает ее вместе с каждым запросом.
HTTP authentication — если сервер запрашивал HTTP авторизацию, то браузер при каждом обращении шлет введенные логин и пароль.

РНР может посылать HTTP заголовки двумя командами — header() и setcookie() .

Просмотр обмена HTTP заголовками
Я очень рекомендую попрактиковаться с HTTP заголовками, посмотреть, как ими обмениваются сервер и клиент.
Для этого есть множество разных способов. Если у вас стоит популярный download manager FlashGet, то можно использовать его. Так же заголовки показывает популярная программа Proxomitron, можно скачать какие-нибудь специальные утилиты.
Для IE можно предложить плагин http://blunck.se/iehttpheaders/iehttpheaders.html
Для браузера Mozilla есть удобный плагин http://livehttpheaders.mozdev.org/
Так же, существует много других утилит, легко находимых в сети по запросу HTTP sniffer.
Обязательно воспользуйтесь любым способом посмотреть HTTP заголовки, которыми обменивается браузер с сервером. Это очень хорошая практика, а так же проверка — что шлет твой скрипт. Удобно при отладке установки кук или проблемах с сессиями.
Примерное представление о пришедших заголовках можно также получить, воспользовавшись функцией getallheaders() . Но следует учитывать, что работает она только если PHP собран, как модуль.

ОЧЕНЬ ВАЖНОЕ ЗАМЕЧАНИЕ
Из того факта, что PHP исполняется на сервере, и посылает результат своей работы браузеру, следует один простой, но очень важный вывод. Что PHP в принципе НЕ МОЖЕТ отобразить в браузере ничего такого, что невозможно было бы сделать средствами html.
ПРЕЖДЕ, чем что-то писать на PHP — попробуйте это сделать чистым HTML.
«Нажатие на Энтер» не переводит строку? А в html вы не пробовали таким образом строки переводить? Не получилось? Какая досада. Прочитайте, как в html сделать перевод строки и приходите снова.

PHP в результате своей работы формирует не картинку с текстами, как вы ее видите на экране монитора! PHP формирует HTML код! И этот код ЗНАЧИТЕЛЬНО отличается от того изображения, которое вы видите на экране. Если у вас что-то не получается, то надо всегда смотреть именно ИСХОДНЫЙ код страницы, а не то, как вам ее рисует браузер. В браузере Internet Explorer исходный код можно посмотреть, выбрав в меню Вид — Просмотр HTML-кода.
Если у вас не работает яваскрипт, сформированный PHP скриптом, или html показывает не то, что вы хотите, то исправить эту проблему очень просто.
1. Сначала пишете нужный яваскрипт или html руками. Если у вас с этим проблемы — обратитесь в соотвествующий форум — по яваскрипту или html. PHP тут не при чём.
2. Сравниваете с тем, что получено из PHP
3. Вносите исправления в PHP скрипт, чтобы текст, отдаваемый им, не отличался от написанного руками.

Браузер не умеет показывать файлы, в которые напихан одновременно и html картинки. Браузер умеет показывать только известные ему типы данных. В частности, это ИЛИ html ИЛИ картинка. Но не вместе. Если картинка — то ОДНА. Несколько картинок подряд браузер показывать не умеет. Браузер умеет показывать HTML, в котором прописаны ССЫЛКИ на несколько картинок.
Пожалуйста, прежде, чем изучать PHP — изучите хотя бы основы HTML! Прежде, чем что-то требовать от PHP — попробуйте сделать это на html.