Хранение данных в wp_posts и wp_postmeta
-
Доброго дня !
Подскажите, пожалуйста, как верно организовать хранение данных, получаемых из формы ввода пользователем, содержащей 6-8 полей ? (Соответственно каждая запись будет иметь 6-8 параметров)
Первоначально была мысль создавать собственную таблицу, но понимание множества уже имеющихся в WP средств и методов работы с таблицамиwp_posts
иwp_postmeta
подсказывает актуальность использования данных таблиц. Если предпочтительнее использовать таблицыwp_posts
иwp_postmeta
, то как верно организовать хранение данных: куда записывать данные 6-8 параметров — в поле post_content добавляемой записи таблицыwp_posts
? или же после отправки формы в поле post_content записывать основной параметр, а все остальные (второстепенные) параметры записывать в таблицуpostmeta
как метаданные после создания соответствующей записи в таблицеposts
?Наведите на верную мысль
Заранее благодарен за любую помощь
-
@yube , понял, занимаюсь) код, который Вы указали
jQuery('form').on('submit', function () { jQuery('input[type=submit]').attr("disabled", true); });
срабатывает, кнопка блокируется, но ‘disabled’ почему-то отменяет отправку формы, страница просто обновляется и ничего не происходит.
Вычитал, что нужно этот код повесить на обработчик формы, при отправке чтобы срабатывал. Прописываю так:if (isset($_POST['heat_send'])) { echo "<script>jQuery('form').on('submit', function(){ jQuery('input[type=submit], button[type=submit]').text('Подождите'); jQuery('input[type=submit], button[type=submit]').attr('disabled', true); return true; });</script>"; include( get_stylesheet_directory() . '/forms/form_heat.php' ); }
Форма отправляется, но кнопка не блокируется. Выходит я не правильно понимаю фразу
нужно этот код повесить на обработчик формы, при отправке чтобы срабатывал
? Если не сложно, поясните, пожалуйста.
нужно этот код повесить на обработчик формы, при отправке чтобы срабатывал
Это имеет смысл для ajax форм. Повторную отправку традиционнымспособом можно предотвратить переходом на страницу без формы. С F5 всё еще хуже 🙂
@yube , спасибо за помощь. В итоге реализовал, добавив фальшивую кнопку «сохранить», которую спрятал изначально, а в момент submit формы настоящую скрываю, лже-кнопку показываю:) Позвольте ещё у Вас спросить, нашел такую цитату:
Если форма отправляется сама на себя, то стоит добавить защиту от повторной отправки при обновления страницы с помощью 303-го редиректа.
header('Location: https://example.com', true, 303); exit();
Не пойму что это значит и что значит форма отправляется сама на себя ?
Не пойму что это значит
Я тоже. Но похоже на «а не пошел бы ты на example.com» 🙂
и что значит форма отправляется сама на себя ?
Думаю, это значит, что url страницы с формой совпадает с атрибутом action этой формы (то же самое, что пустой action).
@yube , спасибо за объяснение. Сегодня пол дня ломаю голову — почему один и тот же код работает на домене, но не хочет работать на поддомене, такое может быть ? (я пытаюсь использовать страницу wp-login.php только для выхода, чтобы запросы на выход из системы продолжали работать, но блокировали все остальное.) :
// Allow logout actions but redirect to the home page for all other wp-login.php requests add_action( 'login_head', 'redirect_home_on_login_form' ); function redirect_home_on_login_form() { if ( ! isset( $_REQUEST['action'] ) || 'logout' !== $_REQUEST['action'] ) { wp_redirect( home_url( '/' ) ); exit(); } } // wp_logout fires after the user's login cookies have been removed add_action( 'wp_logout', 'redirect_home_on_logout' ); function redirect_home_on_logout() { wp_redirect( home_url( '/' ) ); exit(); }
На домене все отрабатывает и происходит редирект, а на поддомене две ошибки типа Warning: Cannot modify header information — headers already sent by(output started at /home/user2077509/www/iepa.efp.by/wp-login.php:88). Если сможете, подскажите в чем разница, почему так происходит ?
такое может быть ?
Всякое может быть. Скажем, на одном залогинены, на другом нет.
Перед
do_action( 'login_head' );
имеет место куча вывода. Редирект делается через заголовки, а их можно устанавливать только до начала вывода. Вот и Cannot modify header information.Понял, @yube , спасибо. Данные экшены не работают и при восстановлении пароля, пробую так на домене:
add_action( 'login_head', 'redirect_home_on_login_form' ); function redirect_home_on_login_form() { if ( ! isset( $_REQUEST['action'] ) || 'logout' !== $_REQUEST['action'] || 'lostpassword' !== $_REQUEST['action'] || 'rp' !== $_REQUEST['action'] ) { wp_redirect( home_url( '/404' ) ); exit(); } }
Письмо для сброса пароля приходит, а вот при переходе по ссылке, которая содержит wp-login.php?action=rp&key=bBlMa4Qpg3uqeKRw6AEf&login=test, происходит редирект 404. Подскажите, пожалуйста, при восстановлении пароля происходят action=’lostpassword’, action=’rp’ и ещё какие-то другие action, которые я не указал в коде и происходит 404 редирект?
при восстановлении пароля происходят action=’lostpassword’,
Внутри wp-login.php используется переменная $action, не имеющая отношения к системе хуков. Это action в смысле «что делаем».
$default_actions = array( 'confirm_admin_email', 'postpass', 'logout', 'lostpassword', 'retrievepassword', 'resetpass', 'rp', 'register', 'login', 'confirmaction', WP_Recovery_Mode_Link_Service::LOGIN_ACTION_ENTERED, );
Еще раз:
wp_redirect
можно выполнять только на хуках, которые срабатывают до начала вывода: ‘login_init’, «login_form_{$action}». Может еще что-то, смотрите внутри wp-login.php.Я понял, @yube , еще раз спасибо, буду разбираться. Значит этот мой способ защиты wp-login.php неправильный. Как вы считаете, стоит смотреть в сторону плагина для защиты wp-login.php или же всё же пытаться что-то делать самому ?
стоит смотреть в сторону плагина для защиты wp-login.php
.htaccess лучше
или же всё же пытаться что-то делать самому ?
Как минимум — разобраться 😉
Читал про способы защиты wp-login.php — первый путем правки .htaccess и второй способ правкой .htaccess и functions.php. @yube , но все эти способы сводились к редиректу на другую страницу при обращении к wp-login.php или изменению адреса wp-login.php, это верный способ? У меня они не заработали, наверное потому что я не создал эту новую страницу, но я не понял что на этой странице размещать.
Ps прошу прощения, если говорю муть, ибо голова уже никакая, продолжу завтра)но все эти способы сводились к редиректу на другую страницу
Я считаю самым правильным
<Files wp-login.php> order deny,allow deny from all allow from my_static_ip </Files>
@yube , хотел ещё спросить — плагин limit login attempts reloaded не распространяется на форму восстановления пароля ? Сегодня поставил, но срабатывал у меня только на форме авторизации. Или я чего-то упустил ? 🙂
@yube , но данный код запретит доступ к wp-login.php всем остальным пользователям, верно?
<Files wp-login.php> order deny,allow deny from all allow from my_static_ip </Files>
тогда ведь никто не сможет авторизоваться на сайте кроме меня, а как быть с остальными пользователями? или я не верно это интерпретирую ?
плагин limit login attempts reloaded не распространяется на форму восстановления пароля ?
Понятия не имею.
или я не верно это интерпретирую ?
Верно. Двух-трех-четырех можно добавить. Но если собираетесь разводить зоопарк, то, конечно, такой метод не годится.
- Тема «Хранение данных в wp_posts и wp_postmeta» закрыта для новых ответов.