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

Конечно здорово будет, если вы хоть немного разбираетесь в HTML / CSS т.к. Вам придется уже по аналогии перетягивать код на свою страницу. PHP язык затрагивать не будем, все необходимые правки, которые нужно будет сделать под себя я покажу.

UPDATE :По откликам читателей, я понял, что нужно что-то более красивое и функциональное, встречайте , ознакомьтесь и посмотрите. Сами выбирайте какая больше понравится)

UPDATE2 : Version 3.0 Адаптивный Лендинг + форма ajax с передачей UTM-меток , ознакомьтесь и посмотрите. Вам понравится

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

Разбор самой формы обратной связи будем изучать на примере посадочной страницы (Landing Page), кстати есть отдельная статья по . Посмотреть как это работает в действии можете по кнопкам расположенным ниже, прикладываю исходники этого одностраничника и главного файла обработчика-php (этот файл и будет обрабатывать и отправлять письмо на email)

После того как скачаете исходники и распакуете архив, вы увидите следующую структуру по файлам:

• image — все изображения, которые используются для самого Landing Page, кнопки и т.д.
• js — javascript скрипты, которые обеспечивают например всплывающее модальное окно на странице и другие визуальные эффекты
• index.html — индексный файл нашего одностраничника
• index1.php — файл обработчик, в который передаются значения из формы, далее формируется письмо из полученных переменных и отправляется на указанный email адрес. Так же index1.php случит в роли промежуточной страницы уведомления об успешной отправке данных с автоматическим перенаправлением обратно на index.html (т.е. наш одностраничник)

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

Взгляните на схему работы взаимодействия всех элементов (страница, форма, обработчик)

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

Заказать обратный звонок Заказажите обратный звонок

Ниже полный исходный код обработчика index1.php, для того чтобы настроить отправку на свой почтовый ящик, поменяйте «[email protected]» на свой, остальное в принципе можно оставить без изменений

С вами свяжутся body { background: #22BFF7 url(img/zakaz.jpg) top -70% center no-repeat; } setTimeout("location.replace("/index.html")", 3000); /*Изменить текущий адрес страницы через 3 секунды (3000 миллисекунд)*/

Вызываем окно и вводим данные для тестовой проверки нашей формы

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

У меня на этом все, старался донести смысл и работу скрипта наилучшим образом. Возникнут вопросы, можете смело обращаться в комментарии или ко мне в VK (смотрите контактные данные). Желаю легкой и продуктивной работы Вам.

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

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

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

// Кэш запроса НЕ РАБОТАЕТ $r = mysql_query("SELECT username FROM user WHERE signup_date >= CURDATE()"); // Кэш запроса РАБОТАЕТ! $today = date("Y-m-d"); $r = mysql_query("SELECT username FROM user WHERE signup_date >= "$today"");

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

Использование ключевого слова EXPLAIN может помочь составить картину того, что делает MySQL для выполнения вашего запроса. Такая картина позволяет легко выявить узкие места и другие проблемы в запросах или структуре таблиц.

Результат запроса EXPLAIN показывает, какие индексы используются, как таблица сканируется и сортируется, и так далее.

Возьмем запрос SELECT (предпочтительно, чтобы он был сложным, с JOIN), добавим перед ним ключевое слово EXPLAIN. Вы можете использовать PhpMyAdmin для этого. Такой запрос выведет результат в прекрасную таблицу. Допустим, мы забыли добавить индекс для столбца, который используется для JOIN:

После добавления индекса для поля group_id:

Теперь вместо сканирования 7883 строк, будут сканироваться только 9 и 16 строк из двух таблиц. Хорошим методом оценки производительности является умножение всех чисел в столбце “rows”. Результат примерно пропорционален прорабатываемому объему данных.

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

В таком случае добавление LIMIT 1 к вашему запросу может улучшить производительность. При таком условии механизм базы данных останавливает сканирование записей как только найдет одну и не будет проходит по всей таблице или индексу.

// Есть ли какой нибудь пользователь из Алабамы? // Так не нужно делать: $r = mysql_query("SELECT * FROM user WHERE state = "Alabama""); if (mysql_num_rows($r) > 0) { // ... } // Вот так будет значительно лучше: $r = mysql_query("SELECT 1 FROM user WHERE state = "Alabama" LIMIT 1"); if (mysql_num_rows($r) > 0) { // ... }

Индексируйте не только основные и уникальные ключи. Если какие-нибудь столбцы в вашей таблице используются для поисковых запросов, то их нужно индексировать.

Как вы можете видеть, данное правило применимо и к поиску по части строки, например, “last_name LIKE ‘a%’”. Когда для поиска используется начало строки, MySQL может использовать индекс столбца, по которому проводится поиск.

Вам также следует разобраться, для каких видов поиска нельзя использовать обычное индексирование. Например, при поиске слова (“WHERE post_content LIKE ‘%apple%’”) преимущества индексирования будут не доступны. В таких случая лучше использовать полнотекстовый поиск mysql или построение собственных решений на основе индексирования.

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

Также связываемые столбцы должны иметь одинаковый тип. Например, если вы связываете столбец DECIMAL со столбцом INT из другой таблицы, MySQL не сможет использовать индекс по крайней мере для одной из двух таблиц. Даже кодировка символов должна быть одинаковой для одинаковых столбцов строчного типа.

// Поиск компании из определенного штата $r = mysql_query("SELECT company_name FROM users LEFT JOIN companies ON (users.state = companies.state) WHERE users.id = $user_id"); // оба столбца для названия штата должны быть индексированы // и оба должны иметь одинаковый тип и кодировку символов // или MySQL проведет полное сканирование таблицы

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

Если вам действительно нужно случайным образом располагать строки в результате вашего запроса, то существует множество лучших способов решить такую задачу. Конечно, это будет реализовано дополнительным кодом, но вы будете спасены от проблемы, которая растет по экспоненциальному закону вместе с ростом объема данных. Дело в том, что MySQL выполняет операцию RAND() (которая занимает время процессора) для каждой отдельной строки в таблице перед тем, как отсортировать ее и выдать вам только одну строку.

// Так делать НЕ НУЖНО: $r = mysql_query("SELECT username FROM user ORDER BY RAND() LIMIT 1"); // Вот так будет лучше работать: $r = mysql_query("SELECT count(*) FROM user"); $d = mysql_fetch_row($r); $rand = mt_rand(0,$d - 1); $r = mysql_query("SELECT username FROM user LIMIT $rand, 1");

Так вы получаете случайное число, которое меньше, чем количество строк в результате запроса, и используете его как смещение в предложении LIMIT.

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

Хорошей привычкой является указание столбца при выполнении SELECT.

// Плохо: $r = mysql_query("SELECT * FROM user WHERE user_id = 1"); $d = mysql_fetch_assoc($r); echo "Welcome {$d["username"]}"; // Так лучше: $r = mysql_query("SELECT username FROM user WHERE user_id = 1"); $d = mysql_fetch_assoc($r); echo "Welcome {$d["username"]}"; // Разница становится существенной на больших объемах данных

Хорошей практикой является использование в каждой таблице поля id, для которого установлены свойства PRIMARY KEY, AUTO_INCREMENT, и оно имеет тип из семейства INT. Предпочтительно - UNSIGNED, так как в этом случае значение не может быть отрицательным.

Даже если в вашей таблице есть поле с уникальным именем пользователя, не делайте его основным ключом. Поля с типом VARCHAR медленно работают в качестве основных ключей. Также структура вашей базы данных будет лучше, если в ней внутри использовать ссылки на записи на основании id.

Кроме того механизм MySQL использует основные ключи для своих внутренних задач, и использование поля id создает оптимальные условия для их решения.

Одним возможным исключением из данного правила являются “ассоциативные таблицы”, которые используются для отношений многие-ко-многим между двумя другими таблицами. Например, таблица “posts_tags” содержит 2 столбца: post_id, tag_id. Они используются для описания отношений между двумя таблицами “post” и “tags”. Описанная таблица может иметь основной ключ, который содержит оба поля id.

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

Отличное объяснение функции mysql_unbuffered_query() из документации PHP:

“mysql_unbuffered_query() отправляет SQL запрос на сервер MySQL без автоматического получения и буферирования строк результата, как это делает функция mysql_query(). Таким образом, сохраняется определенный объем памяти запросами SQL, которые выдают большой набор результата, и можно начинать работать с набором результата сразу же после получения первой строки, не дожидаясь пока запрос SQL будет полностью выполнен.”

Однако существует несколько ограничений. Вы должны либо прочитать все строки либо вызвать mysql_free_result() перед тем, как выполнить следующий запрос. Также нельзя использовать mysql_num_rows() или mysql_data_seek() для набора результата.

Многие программисты создают поле VARCHAR(15) для хранения IP адреса, даже не задумываясь о том, что будут хранить в этом поле целочисленное значение. Если использовать INT, то размер поля сократится до 4 байт, и оно будет иметь фиксированную длину.

Нужно использовать тип UNSIGNED INT, так как IP адрес задействует все 32 бита беззнакового целого.

$r = "UPDATE users SET ip = INET_ATON("{$_SERVER["REMOTE_ADDR"]}") WHERE user_id = $user_id";

Когда каждый отдельный столбец в таблице имеет фиксированную длину, то вся таблица в целом рассматривается как “static” или “с фиксированной длиной записи” . Примеры типов столбцов, которые не имеют фиксированной длины: VARCHAR, TEXT, BLOB. Если вы включите хотя бы один столбец с таким типом, то таблица перестает рассматриваться как "static" и будет по-другому обрабатываться механизмом MySQL.

Таблицы "static" быстрее обрабатываются механизмом MySQL при поиске записей. Когда нужно прочитать определенную запись в таблице, то ее положение быстро вычисляется. Если размер строки не фиксирован, то для определения положения записи нужно время на поиск и сопоставление с индексом основного ключа.

Такие таблицы также проще кэшировать и проще восстанавливать при сбоях. Но они могут занимать больше места. Например, если конвертировать поле VARCHAR(20) в поле CHAR(20), то всегда будут заняты 20 байт вне зависимости от того, используются они или нет.

Использование техники "Вертикальное разделение" дает возможность отделить столбцы с переменной длиной в отдельную таблицу.

Вертикальное разделение - это действие по разделению структуры таблицы по вертикали с целью оптимизации.

Пример 1 : У вас есть таблица, которая содержит домашние адреса, редко используемые в приложении. Вы можете разделить вашу таблицу и хранить адреса в отдельной таблице. Таким образом основная таблица пользователей сократится в размере. А как известно, меньшая таблица обрабатывается быстрее.

Пример 2 : У вас в таблице есть поле “last_login”. Оно обновляется каждый раз, когда пользователь регистрируется на сайте. Но каждое обновление таблицы вызывает кэширование запроса, что может создать перегрузку системы. Вы можете выделить данное поле в другую таблицу, чтобы сделать обновления таблицы пользователей не такими частыми.

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

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

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

Если вы блокируете таблицы на продолжительное время (например, на 30 и более секунд) на высоко нагруженном веб сервере, вы можете вызвать накапливание процессов и запросов, что потребует значительного времени на расчистку или даже приведет к остановке вашего веб сервера.

Если у вас есть скрипт, который удаляет большое количество записей, просто используйте предложение LIMIT для разбиения его на маленькие партии, чтобы избежать описанной ситуации.

While (1) { mysql_query("DELETE FROM logs WHERE log_date discount_code to be a string, but it was sometimes a discount code object. (Thanks, Bill Stoltz)

• BUG: Fixed bug where credit card expiration emails would be sent to users with PayPal Express orders.
• BUG: Fixed bug when updating billing with Stripe.
• BUG: Fixed bug where the archive/search filter was not running for logged out users.
• ENHANCEMENT: Updated Finnish translations. (Thanks, JP Jakonen)
• ENHANCEMENT: Added filter for modifying the order description in Stripe. (Thanks, Rafe Colton)

• BUG: Fixed notifications.php to make sure it really only checks once per day. Also updated the URL checked to notifications.paidmembershipspro.com, which runs on its own server.

• BUG/ENHANCEMENT: Changed the pmpro_button shortcode to pmpro_checkout_button. (The old pmpro_button will also still work. checkout_button works if you have Register Helper installed.)

• BUG: Fixed bug when using a secondary gateway (e.g. PayPal Express) with Stripe as your primary gateway.

• BUG: Fixed bug with updating credit cards through Braintree.
• BUG: Fixed bug with updating credit cards through Stripe.
• BUG: Fixed SQL warnings when generating the pmpro_membership_levelmeta table. (Thanks, itibet on GitHub)
• BUG/ENHANCEMENT: Moved some update billing and checkout related code from the preheaders and page templates into the Braintree and Stripe classes.
• ENHANCEMENT: Added pmpro_billing_order filter that functions similar to pmpro_checkout_order.
• ENHANCEMENT: Added pmpro_billing_before_submit_button hook that functions similar to the pmpro_checkout_before_submit_button hook.
• ENHANCEMENT: Clicking on a report widget no longer takes you to the details page. You have to click the details button. This allows us to add additional functionality to the widgets.
• ENHANCEMENT: Updated reports widgets so the «details» button only shows if a page function is defined for that report. You can now have report widgets without details pages.
• ENHANCEMENT: You can now click on a heading in the Membership Stats report widget to see data for up to 3 of your levels. The first 3 levels per the level ordering are shown.

• BUG: Fixed issue where end dates were being set/saved incorrectly from the edit user/profile page in the dashboard.
• BUG: Fixed warnings in the Braintree PHP library. (Thanks, Travis Shivers)
• BUG: Fixed issue where the filtered $mypost object was not being used in the content filter if the post type was «page». (Thanks, James)
• BUG: Removed the extra class=»input» attribute on the CVV field when the Stripe gateway is used. (Thanks, Rafe Colton)
• BUG/ENHANCEMENT: Changed the number of X placeholders for masked credit cards to 12 (+ the last 4 stored) instead of 13. (Thanks, Rafe Colton)

• FEATURE: The Stripe Webhook has been updated to process subscriptions cancelled from Stripe. PMPro will now cancel memberships for these users instead of sending an email to the admin.
• BUG: Fixed various bugs in the PayPal IPN handler.
• BUG: Fixed search on discount codes page in dashboard. (Thanks, Debjit Saha)
• BUG: Fixed bug in Cancellations report where all-time cancellations were always 0.
• BUG: Fixed link to payment settings on checkout notice. (Thanks, Coen Jacobs)
• BUG: Timezone magic on edit user page in the dashboard to make sure the expiration date you select is the one set.
• BUG: Swapped out deprecated uses of eregi_replace and split.
• BUG/ENHANCEMENT: Now using add_query_arg in the pmpro_url() function. (Thanks, Debjit Saha)
• ENHANCEMENT: Updating stylesheet for WordPress 4.7 and new Twenty Seventeen theme support.
• ENHANCEMENT: Now longer warning of membership levels with cycle numbers > 1 when using the Payflow Pro gateway since Payflow now supports cycle numbers (frequencies) > 1.
• ENHANCEMENT: Updated da_DK translation. (Thanks, bopdoq on GitHub)
• ENHANCEMENT: Added pmpro_include_payment_option_for_paypal filter, which can be set to false to use PayPal WPP without the PayPal Express option.
• ENHANCEMENT: Better dependency checking for Stripe and Braintree gateways.
• ENHANCEMENT: Updated IPN handler and Stripe Webhook handler to use pmpro_cancelMembershipLevel instead of pmpro_changeMembershipLevele. This improves support for the MMPU addon.

• BUG: Fixed bug when using the testing gateway.
• BUG: Avoiding issues where is_user_logged in is not yet available for the pmpro_search_filter() function. (Thanks, d_enajetic)
• ENHANCEMENT: Updated Italian translation. (Thanks again, Angelo)
• ENHANCEMENT: You can now define(‘PMPRO_USE_SESSIONS’, false); in your wp-config.php to force PMPro to skip the call to session_start. Note that PayPal Express and some addons require sessions to function.

• BUG: Fixed issue where «expiring soon» emails were sometimes sent more than needed.
• BUG: Fixed issue where PayPal Standard IPN requests were being rejected if a tax amount was set in PayPal.
• BUG: Fixed issue with Stripe subscription «updates» that were set to fire on «next payment», e.g. if you used Stripe with levels with a non-zero trial amount. When the update processed and created a new subscription, the old subscription was not being deleted and the new subscription ID was not being saved as a new order for future tracking purposes. If you use this feature, please check in Stripe to make sure your users don’t have extra subscriptions.
• BUG: Fixed setting in PayPal/PayPal Express API calls from AUTOBILLAMT to AUTOBILLOUTAMT. This setting is set to AddToNextBilling, meaning that failed payment amounts are added to the next billing cycle’s amount if left unpaid. In most cases, a retry of the original billed amount goes through or the user’s subscription is cancelled. But just in case, this makes sure that outstanding balances are paid. (Thanks, jubstuff on GitHub)
• BUG: Fixed warnings in the setGateway method of the MemberOrder class for cases where the gateway is missing or the class file is not found.
• BUG/ENHANCEMENT: Moved the pmpro_before_change_membership_level hook to fire a little bit earlier to make it easier to determine the old level status/end date/etc before it gets updated. (Thanks, MrVibe on GitHub)
• ENHANCEMENT: Replaced the Force SSL option with an explanation if the entire site is over HTTPS. We are already ignoring the option in these cases.

• BUG: Fixed a bug introduced in 1.8.11 that kept PMPro from tracking coupon code uses. Any checkout with a discount code while running 1.8.11 won’t have properly tracked the discount code use. You may want to adjust your «uses» numbers for your codes, and hand check any reporting/etc that relied on discount codes. Users of the Sponsored Members addon will have been affected too. Discount codes will need to be made manually for any sponsor who checked out.
• BUG: Fix to the expiration warnings code. Making sure it finds all members who are expiring soon while also keeping track of when emails are sent so users don’t get too many emails.
• BUG: Fixed issue where pmpro_before_change_membership_level was running after levels had been changed.
• BUG: Fixed some warnings.
• ENHANCEMENT: Updated Italian translations. (Thanks, Angelo)

• BUG: Fixed issue introduced in 1.8.11 where the pmpro_default_level custom field was being ignored at checkout.
• BUG: Fixed bugs in DB calls made for the compatibility checks for various gateways.
• BUG: Now sending a FREQUENCY parameter for PayPal Payflow orders.

• BUG: Fixed URL used when checking for addon updates.
• BUG: Now enqueueing the jquery.creditCardValidator.js file in Billing preheader.
• BUG: Fixed issues where PayPal IPN updates would sometimes log $0 instead of the actual billing amount.
• BUG: Fixed warnings in the PayPal IPN handler.
• BUG/ENHANCEMENT: Added pmpro_checkout_level filter and now using that filter to apply the_content filters to the level description at checkout. This allows you to turn off the the_content filters (e.g. processing shortcodes) by using remove_filter(‘pmpro_checkout_level’, ‘pmpro_pmpro_checkout_level’); in a custom plugin.
• BUG/ENHANCEMENT: Using the pmpro_confirmation_message filter on the confirmation page whether there is an invoice or not. Now also adding the the_content filters to the confirmation message. You can disable this by using remove_filter(‘pmpro_confirmation_message’, ‘pmpro_pmpro_confirmation_message’); in a custom plugin.
• ENHANCEMENT: Now tracking IPN event ids in order notes for recurring orders.
• ENHANCEMENT: Added pmpro_subscription_ipn_event_processed hook to IPN handler.
• ENHANCEMENT: Added pmpro_set_message filter to edit PMPro error messages. Passes the message and type.
• ENHANCEMENT: Now listing categories in hierarchical format in the Content Settings section of Membership Levels.
• ENHANCEMENT: Added pmpro_areLevelsFree() function to check if all levels in an array of levels are free.
• ENHANCEMENT: Added pmpro_getLevelsCost() — with an s — function to get the combined cost of multiple levels in an array.
• ENHANCEMENT: Added pmpro_getLevelsExpiration() — with an s — function to get the combined expiration text for multiple levels in array.
• ENHANCEMENT: Created the pmpro_getLevelAtCheckout function that modularizes some of the logic of creating the pmpro_level global at checkout.
• ENHANCEMENT: Added pmpro_members_list_user filter used on the admin members list and members list CSV export.
• ENHANCEMENT: Added a 4th parameter $cancel_level to pmpro_changeMembershipLevel(). If set, that level will definitely be cancelled locally and at the gateway. This parameter is also passed to the pmpro_before_change_membership_level and pmpro_after_change_membership_level hook.
• ENHANCEMENT: Added a new function pmpro_cancelMembershipLevel($level_id, $user_id, $old_level_status) that acts as a wrapper to pass the $cancel_level param to pmpro_changeMembershipLevel().
• ENHANCEMENT: Updated the cancel page on the frontend to support the Multiple Memberships per User addon. All memberships are shown. You can cancel individual memberships separately. The language of the confirm button mentions memberships vs account.
• ENHANCEMENT: Added pmpro_getMemberOrdersByCheckoutID($checkout_id) function to support Multiple Memberships per User and others using the checkout_id.
• ENHANCEMENT: Added a refund($order, $transaction_id) method to the PMPro_stripe class. This will be used by the Multiple Memberships per User addon and eventually used in other areas by the core pluginn.

Provided that you have the appropriate permissions, you will be able to see the Members entry on the or in the . Clicking one of these links will bring you to the View all Members page, the default page for the Members List section. There is also a page in this section, where you can search for members registered on the forum.

On the View All Members page, you will see the list of all the members registered on the forum. Pages are used so that there are not too many members listed on one single page. When there is more than one page, the additional pages can be selected from here. On the right side of the "Members List" title bar, every letter of the English alphabet is displayed. These letters are used to jump to the usernames of registered members that begin with that letter, so that you do not have to scroll through several pages to find them. This does not filter out all of the usernames beginning with different letters, but rather serves as an anchor, so you will be directed to usernames that start with the selected letter.

All usernames in the memberlist can be ordered by: Status (Online/Offline), Username, Email, Website, ICQ, AIM, YIM, MSN, Position, Date Registered, and Posts. These column headings are links that can be used to sort the list in ascending or descending order, or to reverse the sort order of the column under the heading that is currently used to sort the list.

This section allows you to do either a simple search for members, or to choose to filter your results by using additional parameters. You can search for members based on their username, email address, messenger nickname, website, or position.

The search results will show matches for the terms that you enter in the search field. If any of the additional search parameters are selected, then the results will also be filtered accordingly. The search does not look only for full-word exact matches, but also for any parts of text that match the search terms. For this reason, if the search term represents only part of the word that you are looking for, then the results may show many more matches than expected.

Some of the additional search parameters relate to information that users can either choose not to include in their profile (messenger nickname, website) or they can choose not to reveal it to the public (email), so using these parameters might not always bring up the results that you are looking for. The results of the search will be more accurate the more letters/words that are used in the search.