PHP _SELF в атрибуте формы action. События и фильтры в WordPress Наблюдательный do php action

Последнее обновление: 1.11.2015

Одним из основных способов передачи данных веб-сайту является обработка форм. Формы представляют специальные элементы разметки HTML, которые содержат в себе различные элементы ввода - текстовые поля, кнопки и т.д. И с помощью данных форм мы можем ввести некоторые данные и отправить их на сервер. А сервер уже обрабатывает эти данные.

Создание форм состоит из следующих аспектов:

    Создание элемента в разметке HTML

    Добавление в этот элемент одно или несколько поле ввода

    Установка метода передачи данных: GET или POST

    Установка адреса, на который будут отправляться введенные данные

Итак, создадим новую форму. Для этого определим новый файл form.php , в которое поместим следующее содержимое:

Вход на сайт Логин:

Пароль:

Атрибут action="login.php" элемента form указывает, что данные формы будет обрабатывать скрипт login.php , который будет находиться с файлом form.php в одной папке. А атрибут method="POST" указывает, что в качестве метода передачи данных будет применяться метод POST.

Теперь создадим файл login.php , который будет иметь следующее содержание:

Чтобы получить данные формы, используется глобальная переменная $_POST . Она представляет ассоциативный массив данных, переданных с помощью метода POST. Используя ключи, мы можем получить отправленные значения. Ключами в этом массиве являются значения атрибутов name у полей ввода формы.

Так как атрибут name поля ввода логина имеет значение login (), то в массиве $_POST значение этого поля будет представлять ключ "login": $_POST["login"]

И поскольку возможны ситуации, когда поле ввода будет не установлено, например, при прямом переходе к скрипту: http://localhost:8080/login.php . В этом случае желательно перед обработкой данных проверять их наличие с помощью функции isset() . И если переменная установлена, то функция isset() возвратит значение true .

Теперь мы можем обратиться к форме:

И по нажатию кнопки введенные данные методом POST будут отправлены скрипту login.php :

Необязательно отправлять данные формы другому скрипту, можно данные формы обработать в том же файле формы. Для этого изменим файл form.php следующим образом:

Вход на сайт Логин:

Пароль:

Безопасность данных

Большое значение в PHP имеет организация безопасности данных. Рассмотрим несколько простых механизмов, которые могут повысить безопасность нашего веб-сайта.

Но вначале возьмем форму из прошлой темы и попробуем ввести в нее некоторые данные. Например, введем в поле для логина "alert(hi);", а в поле для пароля текст "пароль":

После отправки данных в html разметку будет внедрен код javascript, который выводит окно с сообщением.

Чтобы избежать подобных проблем с безопасностью, следует применять функцию htmlentities() :

If(isset($_POST["login"]) && isset($_POST["password"])){ $login=htmlentities($_POST["login"]); $password = htmlentities($_POST["password"]); echo "Ваш логин: $login
Ваш пароль: $password"; }

И даже после ввода кода html или javascript все теги будут экранированы, и мы получим следующий вывод:

Еще одна функция - функция strip_tags() позволяет полностью исключить теги html:

If(isset($_POST["login"]) && isset($_POST["password"])){ $login=strip_tags($_POST["login"]); $password = strip_tags($_POST["password"]); echo "Ваш логин: $login
Ваш пароль: $password"; }

Результатом ее работы при том же вводе будет следующий вывод.

Создает событие (зацепку для произвольной функции). Чтобы функция сработала в момент события её нужно подключить к этому событию с помощью функции add_action() .

Кроме событий в WP есть еще фильтры (filters), принцип работы такой же. Разницы лишь в том, что фильтр должен вернуть полученную переменную, т.е. он фильтрует (изменяет) данные, а событие позволяет запустить пользовательскую функцию в момент срабатывания этого события. Фильтры запускаются функцией apply_filters()

✈ 1 раз = 0.00007с = очень быстро | 50000 раз = 0.03с = скорость света

Хуков нет.

Возвращает

Ничего не возвращает.

Использование do_action($tag, $arg_a, $arg_b, ...); $tag(строка) (обязательный) Название создаваемого хука. $arg_a Значение аргумента, который будет передан.
$arg_b(строка/массив/число/объект/логический) Значение еще одного аргумента...
По умолчанию: аргумент не существует $arg_с(строка/массив/число/объект/логический) Функции можно передавать бесконечно много аргументов... Примеры #1. Пример использования

Эту функцию можно использовать в плагинах, темах и т.д., когда нужно внедрится в процесс выполнения кода, откуда-нибудь из другого места. Например, "зацепку" (хук) (do_action) мы установили в плагине, а "цепляться" за нее будем из файла functions.php в тот момент, когда будет срабатывать наша "зацепка".

Допустим, мы использовали такой код в плагине:

.
Вам лет.

Пример вывода данной программы:

Здравствуйте, Сергей. Вам 30 лет.

Если не принимать во внимание куски кода с htmlspecialchars() и (int) , принцип работы данного кода должен быть прост и понятен. htmlspecialchars() обеспечивает правильную кодировку "особых" HTML-символов так, чтобы вредоносный HTML или Javascript не был вставлен на вашу страницу. Поле age, о котором нам известно, что оно должно быть число, мы можем просто преобразовать в integer , что автоматически избавит нас от нежелательных символов. PHP также может сделать это автоматически с помощью расширения filter . Переменные $_POST["name"] и $_POST["age"] автоматически установлены для вас средствами PHP. Ранее мы использовали суперглобальную переменную $_SERVER , здесь же мы точно так же используем суперглобальную переменную $_POST , которая содержит все POST-данные. Заметим, что метод отправки (method) нашей формы - POST. Если бы мы использовали метод GET , то информация нашей формы была бы в суперглобальной переменной $_GET . Кроме этого, можно использовать переменную $_REQUEST , если источник данных не имеет значения. Эта переменная содержит смесь данных GET, POST, COOKIE.

15 years ago

According to the HTTP specification, you should use the POST method when you"re using the form to change the state of something on the server end. For example, if a page has a form to allow users to add their own comments, like this page here, the form should use POST. If you click "Reload" or "Refresh" on a page that you reached through a POST, it"s almost always an error -- you shouldn"t be posting the same comment twice -- which is why these pages aren"t bookmarked or cached.

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.

2 years ago

Worth clarifying:

POST is not more secure than GET.

The reasons for choosing GET vs POST involve various factors such as intent of the request (are you "submitting" information?), the size of the request (there are limits to how long a URL can be, and GET parameters are sent in the URL), and how easily you want the Action to be shareable -- Example, Google Searches are GET because it makes it easy to copy and share the search query with someone else simply by sharing the URL.

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.

4 years ago

Do-while loops can also be used inside other loops, for example:



This version is easier to read and understand. And arguments for code golf are invalid as well as this version is 3 lines shorter.

In conclusion, although you can certainly write code that abuses the `break` keyword, you shouldn"t in practice. Keep the code easy to read and understand for whoever inherits your code. And remember, code is for humans not computers.

10 years ago

I"m guilty of writing constructs without curly braces sometimes... writing the do--while seemed a bit odd without the curly braces ({ and }), but just so everyone is aware of how this is written with a do--while...

a normal while:


a do--while:


Also, a practical example of when to use a do--while when a simple while just won"t do (lol)... copying multiple 2nd level nodes from one document to another using the DOM XML extension

Мы создали фундамент для будущего плагина, который распознает система WordPress. Сегодня мы займемся непосредственно изменением базового функционала системы.

Поможет нам в этом система «хуков» (hooks), «событий» (actions) и фильтров (filters). Эти три понятия и есть основа каждого плагина для WordPress.

Hooks

В WordPress есть два типа хуков:

  • Action hook: помечает место в коде, которое выполняет определенное действие, например, необходимо внести какие-либо данные и сохранить в базе.
  • Filter hook: помечает фильтр, который будет изменять какое-либо значение (переменную), так что в дальнейшем код будет использовать модифицированное значение.
Actions

Работа с событиями (actions)

Общая логика управления событиями в WordPress проста:

  • Пометить место, где действие должно выполниться с помощью хука (action hook) с необходимыми параметрами.
  • Создать функцию, которая будет выполнять нужные действия, используя параметры переданные хуком.
  • Зарегистрировать событие, которое будет выполняться при срабатывании хука, с определенным приоритетом.
  • Когда WordPress загружает страницу и находит hook, система выполнит все функции, которые зарегистрированы на этот хук.
  • Для выполнения первого пункта система предоставляет функцию ‘do_action’:

    Do_action($tag, $arg_1, $arg_2, ... , $arg_n);

    Она принимает следующие аргументы: $tag – название “хука”, $arg_1, $arg_2, … , $arg_n – параметры, с которыми будет вызвана функция. Аргументов может быть любое количество, либо 0.

    Система сама по себе имеет много уже определенных хуков:

    Do_action("init");

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

    Do_action("save_post", $post_id, $post);

    В этом примере хук срабатывает при сохранении записи с двумя аргументами post_id — идентификатор записи и post — сама запись.

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

    Do_action("my_truly_custom_hook");

    Когда мы создали хук и написали функцию, нам необходимо зарегистрировать функцию с помощью «add_action»

    Add_action($tag, $function_to_add, $priority, $accepted_args_number);

    Функция ‘add_action’ принимает два обязательных параметра: $tag: название соответствующего хука и $function_to_add: имя функции, которую необходимо вызвать. Другие два параметра дополнительные: $priority: целочисленная переменная, которая определяет порядок выполнения функции (по-умолчанию — 10), $accepted_args_number: количество аргументов, которое принимает функция (по-умолчанию — 1).

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

    Function msp_helloworld_footer_notice(){ echo "Hello, I"m your custom notice"; } add_action("wp_footer", "msp_helloworld_footer_notice");

    В этом примере мы создали функцию, которая просто выводит разметку для оповещения и зарегистрировали её в ‘wp_footer’. Как только мы добавим этот код в файл нашего плагина (см. предыдущий ) мы увидим результат на странице:

    Оповещение плагина WordPress

    Работа с фильтрами (filters)

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

    Функция-фильтр будет принимать это значение и преобразовывать его для дальнейшего использования. Хуки для фильтров немного отличаются от хуков для событий (action hooks).

    Apply_filters($tag, $value_to_filter, $arg_1, $arg_2, ... , $arg_n);

    Функция ‘apply_filter’ создает хук для фильтра с именем $tag и обязательным параметром $value_to_filter (он может быть пустым, но должен быть объявлен). Остальные аргументы необязательны работают так же как и для событий.

    Filter_function($value_to_filter, $arg_1, $arg_2, ... , $arg_n){ //фильтр return $value_to_filter; //значение необходимо вернуть }

    Это «скелет» фильтра, который демонстрирует, что фильтр должен:

  • принимать хотя бы 1 аргумент;
  • возвращать модифицированное значение.
  • add_filter($tag, $function_to_add, $priority, $accepted_args);

    Функция ‘add_filter’ регистрирует функцию с названием, содержащимся в $function_to_add для хука $tag. Остальные аргументы - $priority и $accepted_args — работают так же как и у хуков для событий.

    Рассмотрим пример: обычная для плагина задача — добавить что-нибудь в конец поста. Если подробнее рассмотреть функцию ‘the_content’, которая используется для вывода содержимого записи, мы найдем такой хук:

    $content = apply_filters("the_content", $content);

    Используя его мы можем легко добавить что-либо в конец поста.

    Function msp_helloworld_post_footer($content) { $content .= "

    Hello, I"m your custom post footer

    "; return $content; } add_filter("the_content", "msp_helloworld_post_footer", 100);

    Обратите внимание, что мы используем большое число для приоритета, что убедиться, что до выполнения ‘msp_helloworld_post_footer’ все стандартные фильтры отработают. После включения кода в наш плагин мы увидим результат:


    Как найти хук

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

    «Кодекс» WordPress предоставляет списки хуков для фильтров и событий Action Reference и Filter Reference .

    Дополнительные действия с хуками

    Так же как и добавить, хук можно удалить, используя похожий синтаксис.

    Удалить события можно так:

    Remove_action($tag, $function_to_remove, $priority, $accepted_args); remove_all_actions($tag, $priority);

    Как вы догадались, ‘remove_action’ удаляет определенное событие, зарегистрированное для данного хука (необходимо правильно указать приоритет и количество аргументов, так как было указано при регистрации), и ‘remove_all_actions’ помогает удалить все события, зарегистрированные для хука (если приоритет опущен, функция удалит все события).

    Фильтры можно удалять так же:

    Remove_filter($tag, $function_to_remove, $priority, $accepted_args); remove_all_filters($tag, $priority);

    API для плагинов в WordPress также предоставляет функции для проверки зарегистрирована ли функция для данного хука:

    Has_action($tag, $function_to_check); has_filter($tag, $function_to_check);

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

    If("hook_to_check_name" === current_filter()){}

    Несмотря на название ‘current_filter’ работает не только с фильтрами но и с событиями.

    Нетривиальный пример

    Оживим «скелет» нашего плагина, который мы подготовили в прошлом уроке.

    Заполним файл ‘core.php’ (главная часть нашего плагина, в которой сосредоточена основная часть функций) кодом, который решает задачу, которая реально может возникнуть в ходе работы. Для её решения мы будем использовать actions и filters.

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

    Создадим собственную таксономию для обработки имя автора и его короткой биографии. Мы сможем использовать имя автора как другие термины таксономии (теги, например) в посте. Код:

    /** регистрация фильтров и событий **/ function msp_helloworld_init(){ add_action("init", "msp_helloworld_taxonomies"); add_filter("the_content", "msp_helloworld_author_block_filter"); add_filter("post_class", "msp_helloworld_post_class"); } add_action("plugins_loaded", "msp_helloworld_init"); /** taxonomy **/ function msp_helloworld_taxonomies(){ $args = array("labels" => array("name" => "Guest authors", "singular_name" => "Guest author"), "show_in_nav_menus" => false); register_taxonomy("gauthor", array("post"), $args); } /** разметка блока автора **/ function msp_helloworld_author_block(){ global $post; $author_terms = wp_get_object_terms($post->ID, "gauthor"); if(empty($author_terms)) return; $name = stripslashes($author_terms->name); $url = esc_url(get_term_link($author_terms)); $desc = wp_filter_post_kses($author_terms->description); $out = ""; $out .= "This is a guest post by {$name}"; $out .= "{$desc}"; return $out; } /** добавить разметку в конец поста **/ function msp_helloworld_author_block_filter($content){ if(is_single()) $content .= msp_helloworld_author_block(); return $content; } /** добавить CSS class к посту **/ function msp_helloworld_post_class($post_class){ global $post; $author_terms = wp_get_object_terms($post->ID, "gauthor"); if(!empty($author_terms)){ $post_class = "gauthor"; } return $post_class; }

    Как видите, мы создали функцию для регистрации собственной таксономии и привязали её к хуку ‘init’. После мы создали шаблон, отвечающий за отображение блока автора, используя функцию WordPress ‘wp_get_object_terms’. После мы вставили блок с информацией об авторе в конец поста с помощью фильтра ‘the_content’. И, наконец, мы добавили собственный CSS класс. Результат работы: