форма и обработчик в одном файле php
Обработка форм сайта с помощью PHP
Введение
Формы используют для отправки какой-либо информации на сервер, которую необходимо как-то обработать.
Места использования форм:
Создаём форму на HTML
Код формы необходимо помещать в HTML документа.
Я пропущу скелет документа дальше, чтобы было более понятно.
В атрибут action нужно указать обработчик формы (PHP-скрипт). Если поле пусто, значит, обработку формы выполнил тот скрипт, в котором расположена сама форма. В атрибут method нужно указать метод отправки формы (post или get). У каждого свои плюсы и минусы. Вкратце: post отправляет данные так, что пользователь не может их увидеть, а get — так, что они видны в URL-строке браузера.
Наглядный пример get:
Наглядный пример post:
Немного по PHP:
Создаём обработчика формы
Мы перешли к самому интересному моменту статьи. Если мы обрабатываем форму на другой странице (action=»example.php»), то после нажатия кнопки подтверждения вас перекинет на указанную страницу.
Если action пуст, то страница с формой перезагрузится.
В самом верху скелета документа (перед ) открываем теги PHP и обрабатываем форму:
Теперь если форма не прошла проверку, то все данные стираются, и нужно их вводить заново.
Давайте доработаем форму, чтобы исправить это, а также изменим место вывода ошибок.
В самом верху PHP-тега заводим 2 новые переменные, которые по стандарту пусты:
В проверке на пароль:
В проверке на логин:
.= означает то, что мы берём прошлую строку (пусто) и прибавляем к этому наше сообщение.
В форме HTML:
Теперь доработаем форму, чтобы она сохраняла значения полей.
В самом начале добавляем 2 переменные:
В начало проверки на ‘нажата ли кнопка отправки’ добавляем:
И немного изменяем нашу HTML-форму:
Добавляем тег value, чтобы указать стандартное значение поля. Теперь если выдаётся ошибка, то значения полей сохраняются, и пользователю нужно не заново их вводить, а только исправить ошибку.
Заключение
Как видите, создать хорошую форму на PHP не так уж и сложно. Проверки, которые я показал в этой статье, не обязательно должны быть. Вы можете придумывать свои (любые) проверки на поля ввода, используя PHP. Надеюсь, что вам понравилась моя статья, и вы выучили что-то новое.
Всем спасибо за внимание!
Итоговый код страницы с формой + обработчика:
обработка нескольких форм в php
Написать простейшую форму с её последующей обработкой сможет, пожалуй, каждый. Но начинающие php-программисты (а иногда и более опытные) встают в тупик: а что делать, если форм на странице 2 и обрабатываются они одним и тем же скриптом? На самом деле, здесь нет ничего сложного. Достаточно знать один момент: как именно браузер отрабатывает эти ситуации.
Допустим, на странице есть 2 формы. Одна отвечает за регистрацию, другая — за авторизацию. В этом случае не будет ничего удивительного, если обрабатывать их будет один файл. Для однозначного и быстрого (в самом деле, если форм будет ещё больше и их данные пересекаются глупо просматривать ворох параметров и создавать чуть ли не искусственный интеллект, пытаясь определить, что же вообще требуется) Определения того, какая из форм была инициирована пользователем, достаточно соблюсти 2 момента.
Как известно, за отправку формы отвечает элемент input с типом submit. Если данному элементу присвоить имя (name), сможем по этому имени определить, какая же из форм вызвана. Код будет примерно таким:
Формы практически полностью идентичны. Отличаются они только именами тегов input. В скрипте form.php остаётся только обработать эти ситуации. Исполняем:
Несмотря на то, что код получения логина одинаков, следует понимать, что в первом случае он поступил из формы № 1, а вот втором — из № 2. При активации формы браузер передаёт элементы только этой самой формы. Другие формы обработаны не будут.
Ну и конечно же, ничего не мешает давать элементам разных форм одинаковые имена. В данном примере вполне можно заменить имена login1 и login2 на login (и в html коде, и в скрипте-обработчике form.php).
Дополнение
Для некоторых тема оказалась не раскрыта. Что же, накидал небольшой php-файлик с примером определения отправляемой формы. Надеюсь, живой пример окажется более нагляден.
Работа с формами в PHP
Формы
Формы — это часть языка HTML. Формы нужны для передачи данных от клиента на сервер. Чаще всего формы используются для регистрации пользователей, заполнения анкет, оформления заказа в интернет магазине, и так далее.
Через формы можно отправлять как простую текстовую информацию, так и файлы.
Большую часть времени программирования на PHP вы будете так или иначе работать с формами и данными из них.
HTML описывает то, из каких элементов состоит форма, и как она выглядит. Но без принимающей стороны, то есть сервера, который принимает эти данные и обрабатывает их нужным образом, создавать формы нет никакого смысла.
PHP содержит множество средств для работы с формами. Это позволяет очень просто решать типичные задачи, которые часто возникают в веб-программировании:
Практически любой современный сайт содержит как минимум несколько разных HTML-форм.
Отправка формы
Рассмотрим один типичный пример — форма обратной связи. Для связи пользователей с авторами сайта, как правило, используются формы обратной связи, где человек указывает имя, почту для обратной связи и текст своего сообщения.
Такая форма в HTML может выглядеть следующим образом:
Это очень простая форма, состоящая из трёх полей и одной кнопки отправки.
Почти весь приведённый код описывает внешний вид и содержание формы, но следует обратить внимание на два атрибута тега
Тут есть два важных отличия от первого примера:
PHP автоматически сохраняет все загруженные файлы во временную папку на сервере. Но хранить там файлы нельзя, потому что эта директория периодически очищается, и ссылку на такой файл нельзя дать на сайте. Решение здесь только одно — переместить загруженный файл в другую папку. Перемещение файла всегда выполняют сразу после загрузки.
Перемещение загруженного файла
Код для перемещения файла в новую папку:
Функция move_uploaded_file() выполняет два действия:
Валидация формы
Валидация формы — это проверка содержимого её полей. Задача такой проверки — убедиться, что необходимые поля заполнены, а значения в них соответствуют ожидаемому формату.
Так, например, при регистрации пользователя на сайте, он должен заполнить поля с адресом электронной почты и придумать себе пароль. Оба поля обязательны к заполнению, но значение из поля email также должно быть корректным email-адресом.
Помимо текстовых значений формы, можно проверять формат и размер загружаемых файлов.
Общий подход к валидации
При выполнения валидации любой формы порядок действий будет всегда одним:
Обработка форм в PHP. Как это делать правильно в 2020 году
Это достаточно «классическая» задача в PHP — приём и отправка обычной формы. Давным-давно, ещё во времена PHP 4, в книгах приводился пример того как это делать. Это всегда был один php-файл, где размещался и обработчик формы, и html-код вывода формы, и вывод ошибок. Понятно, что на заре рождения PHP, говорить о каком-то разделении кода или даже о культуре программирования не приходится. Но, недавно я случайно наткнулся на книгу о PHP 7 2018 года выпуска, где рассказывается об основах языка, классах, есть даже глава о PostgreSQL и даже описано несколько ООП-шаблонов проектирования.
Я с удивлением обнаружил, что до сих пор приводится код из PHP 4, как будто бы последних 20 лет развития PHP-программирования и не было. Сами посмотрите: это я сохранил скриншот. То есть вместо того, чтобы учить студентов нормальным практикам, до сих пор предлагается код 20-летней давности.
Чтобы продолжить, давайте определимся что именно неверно в таком подходе.
Код в одном файле — это хорошо или плохо? Хорошо, что это один файл, то есть перенос его будет немного проще. С другой стороны, часто ли вообще требуется куда-то его перемещать? Вряд ли.
Дальше. В файле смесь HTML и PHP. Если вынести код обработчика отдельно, то это уже упростит дальнейшую поддержку. Кстати о поддержке кода.
Поддержка кода — это такая его организация, которая позволит без мата и полной переделки доработать его в любой момент — через месяц или год, любым другим php-программистом. Сюда включается форматирование, а также логическая организация файлов. Форма, конечно, очень простой пример, но он всё равно должен быть сделан по правилам.
То есть на лицо ещё одна проблема — неверная логика работы скрипта. Даже в моих первых книгах вводились более сложные if/else условия, чтобы корректно завершить вывод html-кода.
Всё, хватит лирики, покажу как это нужно делать правильно в 2020 году. 🙂
Базовое правило — логика должна быть разделена на файлы. При отправке формы есть два базовых состояния: вывод самой формы и приём post-данных от формы. HTML-вывод, в свою очередь должен делиться на:
Поскольку нам нужен корректный HTML, то нужно вынести ещё и начальную часть html (секция HEAD) и конечную (BODY, HTML).
Основной (запускающийся) php-файл обычно называется фронт-контроллер (front controller). Да, этот термин больше из ООП, но в подавляющем большинстве php-модулей (и приложений), всегда есть точка входа, которая дальше уже подсоединяет все остальные файлы. Это функция контролёра, которая содержит основную логику модуля/приложения.
В нашем случае пусть это будет index.php:
Форма собирается из нескольких файлов. Каталог layout хранит именно html-вывод. То есть, когда станет задача доработать дизайн формы, достаточно будет поправить какой-то один простой layout-файл.
Файл layout/start.php содержит начальную часть html-страницы:
Файл end.php просто корректно закрывает HTML:
Файл form.php содержит форму:
Рассмотрим цепочку выполнения данного участка кода.
Если форма была отправлена, то происходит подключение action/post.php — это и есть обработчик формы.
Здесь важно то, что есть логика выполнения, но нет непосредственного html-вывода: мы разделяем html-вёрстку от php-кода.
Файл result.php выводит список отправленных данных.
А файл error.php выводит список ошибок.
Такой подход к построению php-модуля (или приложения) наиболее правильный. Если есть возможность, то разделяйте php и html-код по разным файлам. Это особенно актуально для проектов с более сложной логикой.
Часто стоит задача передать в layout-файл какие-то данные. Например название формы, или уже введенные данные, чтобы пользователь их заново не вводил, а только поправил. Лучший способ это сделать — именно через массив. Причём такой, где заранее оговариваются обязательные ключи. Это позволяет избежать дополнительных isset-проверок при их выводе.
Это достаточно простой шаблонизатор PHP.
Аля-MVC
Нетрудно заменить, что по своей сути код соответствует концепции MVC.
Контролёр выполняет основную логику модуля. В нашем случае он совпал с фронт-контроллером, но обычно фронт-контролёр — это уровень приложения, а просто контролёр — это уровень модуля.
Дальше контролёр дёргает определенную модель — в нашем случае это action-файлы. В модели происходит работа с данными и дальше модель передаёт управление в представление (view) — у нас это layout-файлы.
То есть у нас управление передаётся по цепочке: controller → model → view. Есть ещё один вариант, когда контролёр передаёт данные в модель, модель возвращает результат обратно, а потом контролёр их передаёт уже в представление. То есть вариант MVC будет определяться уже задачей или архитектурой приложения.
Валидация данных
И в заключение небольшой момент о валидации данных. Очень часто валидация — чуть ли не половина кода модели (action-файла), поэтому часто её также выносят в отдельный файл.
Работа с формами
Пример #1 Простейшая форма HTML
Пример #2 Выводим данные формы
Пример вывода данной программы:
В PHP можно также работать и с XForms, хотя вы найдёте работу с обычными HTML-формами довольно комфортной уже через некоторое время. Несмотря на то, что работа с XForms не для новичков, они могут показаться вам интересными. В разделе возможностей PHP у нас также есть короткое введение в обработку данных из XForms.
User Contributed Notes 3 notes
You should use the GET method when your form is, well, getting something off the server and not actually changing anything. For example, the form for a search engine should use GET, since searching a Web site should not be changing anything that the client might care about, and bookmarking or caching the results of a search-engine query is just as useful as bookmarking or caching a static HTML page.
POST is not more secure than GET.
Security is only a consideration here due to the fact that a GET is easier to share than a POST. Example: you don’t want a password to be sent by GET, because the user might share the resulting URL and inadvertently expose their password.
However, a GET and a POST are equally easy to intercept by a well-placed malicious person if you don’t deploy TLS/SSL to protect the network connection itself.
All Forms sent over HTTP (usually port 80) are insecure, and today (2017), there aren’t many good reasons for a public website to not be using HTTPS (which is basically HTTP + Transport Layer Security).
As a bonus, if you use TLS you minimise the risk of your users getting code (ADs) injected into your traffic that wasn’t put there by you.