Изучение WP_User_Query

Содержание материала:

pre_user_query tutorial: hiding the user with the exact ID, hiding the users by the role, extending the user search

First of all you should know one important moment. There are two base user query action hooks: pre_get_users — it fires before WP_User_Query has been parsed and allows you to change some query vars like include, exclude, order, orderby etc. pre_user_query fires after the user query has been parsed but before the query is executed. […]

First of all you should know one important moment. There are two base user query action hooks:

  1. pre_get_users — it fires before WP_User_Query has been parsed and allows you to change some query vars like include , exclude , order , orderby etc.
  2. pre_user_query fires after the user query has been parsed but before the query is executed. Do you see the difference?

Let’s begin with the base example, just copy the following code to your current theme functions.php file and open a page with the user list. It can be your administration «Users» page.

I hope you already know what print_r() function is.

And one more thing, if your WordPress version is lower that 3.1, the following examples won’t work for you (try to use pre_user_search instead or update your WordPress).

1. How to completely hide the user with the exact ID from your website.

Okay, this user will not be displayed on the website or inside administration area at all. How to archieve it? With the help of pre_user_query of course.

  • You can move the if condition outs >

Do not worry about that — there are plenty of filters that can help you.

2. How to remove the ability for other users to view administrators in user lists?

It is the more interesting example than the previous one, it based on the same principle, but you can see the complex SQL query in it.

Perhaps you know that user roles are stored in wp_usermeta table (change wp_ to your database prefix) under the wp_capabilities meta_key. So, in the example above we got all the users which has administrator word in their wp_capabilities values.

3. Extend the user search by custom meta_keys from wp_usermeta or custom columns from the other tables.

By default WordPress allows to search users by predefined columns ( user_login , user_email , user_url , display_name , ID and user_nicename ). You can also use the user_search_columns filter to exclude some of the predefined columns from the search.

But pre_user_query allows you to search by a first name, a last name, another user meta key or take wp_posts table for example and search by post titles, this user has been published.

Related Posts

Misha Rudrastyh

I love WordPress, WooCommerce and Gutenberg so much. 10 yrs of experience.

Need some custom developer help? Let me know

Need some help with WordPress?

If you need some professional developer help, I will be happy to assist you.

Comments — 16

Hi Misha, thanks for the good tips and explanations!

About the user counts you say:

— “Do not worry about that — there are plenty of filters that can help you”.

Can you mention what are they?

For example: I like to exclude all users of a role in this count.

WordPress цикл на основе WP_query()

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

WordPress цикл на WP_Query()

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

Пример: архив произвольного типа записей

Предположим нужно на странице вывести записи произвольного типа. Для этого нам потребуется создать новый шаблон страницы, на которой мы будем использовать новый WordPress цикл на основе WP_Query(). Код будет выглядеть следующим образом:

В данном примере вы можете увидеть где начинается новый WordPress цикл, и где он заканчивается. Обращаю ваше внимание на массив $args, который содержит в себе параметры цикла, на основе которых получаются нужные нам записи. Затем создается новый цикл с помощью функции $acsessuar = new WP_Query($args), и если есть посты удовлетворяющие нашим параметрам, то они выводятся на странице.

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

Подобные WordPress циклы на основе WP_Query можно использовать несколько раз на странице. Напомню, что WordPress циклы можно строить также с помощью классов query_posts и get_posts.

Параметры WP_Query для построения WordPress циклов

Для построения циклов WP_Query необходимо знать некоторые параметры, которые позволят вам построить нужный цикл. Основные параметры WP_Query:

‘post_type’ => », — тип записей

‘posts_per_page’ => 10, — количество выводимых записей на странице

‘category’ => , — вывести посты из данной категории (следует указать ID категории)

Также вы можте использовать множество других параметров для построения циклов. Все параметры для WP_query, get_posts и query_posts идентичны, и вы можете найти их на странице с параметрами WP_query.

Работа с WP_Query: Использование цикла

Как было сказано в вступительной статье, мы начинаем разбор класса WP_Query. Напомним, что работу с данным классом можно разделить на четыре этапа:

  • передача аргументов запроса
  • выполнение запроса
  • прохождение по результату в цикле
  • завершение: сброс данных постов

В этом уроке мы рассмотрим несколько способов использования циклов, для прохождения по результатам запроса WP_Query .

Циклы

Без цикла невозможно отобразить контент страницы.

Итак, цикл состоит из следующих этапов:

  • if( $query->have_posts() ) проверяет наличие результата.
  • while( $query->have_posts() ) выполняет внутренний код для каждого поста, полученного в результате выполнения запроса.
  • $query->the_post() осуществляет доступ к посту.

Пример рабочего цикла с использованием класса WP_Query :

После цикла следует вызвать функцию wp_reset_postdata() .

Структура цикла

Структура цикла напрямую зависит от данных, которые вы хотите вывести. Вот пример вывода названия постов, изображения и выдержки.

Детали: проверка наличия контента

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

Чтобы этого избежать, можем осуществить проверку, воспользовавшись условным выражением if :

Сначала мы проверяем наличие постов, выводим заголовок, а затем и сами посты.

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

Запуск дополнительных запросов

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

В данном примере мы выводим изображение только для первого поста, а для всех последующих только название:

В этом примере использовались запросы с следующими параметрами:

  • ‘posts_per_page’ => ‘1’ , в первом запросе, вывод самого свежего поста.
  • ‘offset’ = ‘1’ , во втором запросе, смещение на один запрос, который уже был извлечён на первом шаге.

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

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

Заключение

Без цикла, WP_Query абсолютно бесполезен. В цикле как раз и происходит вывод данных, которые мы хотим видеть на странице.

В этом уроке мы рассмотрели несколько примеров использования цикла: простой вывод данных; вывод, используя связку if( $query->have_posts() ) и while( $query->have_posts() ) . Так же нами был рассмотрен пример отправки запросов с параметрами.

Данный урок подготовлен для вас командой сайта ruseller.com
Источник урока: http://code.tutsplus.com/tutorials/mastering-wp_query-using-the-loop—cms-23031
Перевел: Станислав Протасевич
Урок создан: 6 Октября 2015
Просмотров: 5415
Правила перепечатки

Топ-пост этого месяца:  Как вставить в html5 видео обзор нового тега и его атрибутов

5 последних уроков рубрики «WordPress»

Почему WordPress лучше чем Joomla ?

Этот урок скорее всего будет психологическим, т.к. многие люди работают с WordPress и одновременно с Joomla, но не могут решится каким CMS пользоваться.

Про шаблоны WordPress

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

Самые первые настройки после установки движка WordPress

Сегодня мы вам расскажем какие первые настройки нужно сделать после установки движка WordPress. Этот урок будет очень полезен для новичков.

10 стратегий эффективного продвижения статей в блогах на WordPress

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

Топ WordPress альтернатив для создания персонального сайта

Нужен персональный сайт, но вы не хотите задействовать WordPress? Тогда данная подборка для вас.

Мета-данные в WordPress: введение

Один из факторов, который делает WordPress мощным CMS инструментом — это возможность использовать таблицу wp_postmeta для хранения собственных полей. Эти поля могут содержать дополнительную информацию, например SEO-поля, добавленные SEO плагином, или могут быть использованы для отображения дополнительного контента клиентской части.

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

Обучение работе с этими данными — хороший способ выучить базовые понятия PHP, такие как массивы, циклы и объекты. Чтобы полностью овладеть мета-данными WordPress, вы должны овладеть всеми видами массивов.

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

Что такое мета-данные записи?

Самое техническое определение мета-данных записи — это любая информация, хранимая в таблице wp_postmeta . По умолчанию там не так уж много информации, но плагин или тема в любой момент могут добавить свое поле, а данные, введенные в это поле, будут храниться в таблице wp_postmeta . Хороший пример — SEO-поля, добавляемые SEO-плагином. Например, вспомните мета-описание вашего поста. Это поле хранится в таблице wp_postmeta .

Также собственными полями могут быть дополнены профили пользователей WordPress. И как для таблицы wp_posts есть таблица wp_postmeta , так данные для пользователей хранятся в таблице wp_usermeta , а не в таблице wp_user .

В этой серии статей мы не будем говорить о том, как добавлять собственные поля в WordPress — это отдельная тема. Собственные поля могут быть добавлены в редакторе записи с помощью мета-блока » Произвольные поля «, могут быть добавлены напрямую плагином или темой, а также через использование специального фреймворка, по типу Pods или Advanced Custom Fields .

Технически, мета-данные записи — это любая информация, хранящаяся в таблице wp_postmeta . Как мы упоминали ранее, хороший пример мета-данных записи — поле мета-описания, которое добавляется плагинами типа WordPress SEO.

Методы получения мета-данных

Использование get_post_meta()

WordPress предоставляет множество способов получения мета-данных для записи.

С помощью get_post_meta() мы можем получить только одно поле, указав его. Например, чтобы получить поле под названием ‘ foo ‘ из текущей записи в цикле, мы можем сделать:

Обратите внимание, что последний переданный нами аргумент — true . Этот аргумент под названием » single » определяет, хотим мы получить в ответ отдельное значение или массив значений.

Использование WP_Query

Иногда мы хотим сделать целый цикл вокруг мета-данных, и в этом случае очень пригодится WP_Query . WP_Query позволяет нам делать так называемый «мета-запрос», где запрос на записи основывается на мета-полях и возвращает записи, которые содержат значения, соответствующие запрашиваемым. Результатом будет коллекция, по которой мы можем проходить в цикле.

Например, представьте, что у нас есть поле под названием » author_name » и мы хотим вернуть все записи, где в поле author_name содержится значение ‘ Tolkien ‘. WP_Query позволяет нам делать это очень просто — мы рассмотрим это подробнее в следующем руководстве этой серии.

Не записями едиными

Мета-данные есть не только у записей. Например, вы знаете все поля, которые доступны в профиле пользователя? Это мета-поля, но хранятся они не в wp_postmeta , а в таблице wp_usermeta .

В результате, у нас есть отдельные функции и классы для мета-данных пользователя. Функции get_user_meta() и get_author_meta() — эквивалент аналогичным командам записей. У WP_Query тоже есть свой эквивалент для пользователей — WP_User_Query .

Объекты или массивы

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

Звучит страшно? Не бойтесь! В этой серии статей мы расскажем о том, как читать многомерные массивы для того, чтобы получить нужную вам информацию.

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

В некотором роде объекты похожи на массивы — они могут содержать массивы данных. Но к объекту вы можете применять любую функцию класса. То есть, мы можем не только использовать объект WP_Query для возвращения значения мета-поля, но также можем использовать его внутренние методы, самый популярный из которых — the_post() .

В следующем выпуске…

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

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

Источник: code.tutsplus.com

Насколько полезным был этот пост?

Нажмите на звезду, чтобы оценить этот пост!

Средний рейтинг: 4.8 / 5. Количество голосов: 25

Mastering WP_User_Query

After all those previous parts, we’re done going through the WP_Query class—but that doesn’t mean that we’re done with the series! It’s time to meet WP_Query ‘s brother and sister classes: WP_User_Query , WP_Comment_Query , WP_Meta_Query and WP_Date_Query .

In this part, we’re going to learn about using the WP_User_Query class to query users in WordPress.

What Is WP_User_Query?

You probably get the idea of what WP_User_Query is by merely reading its name. Yes, nobody would expect to see WP_User_Query working with the «Tag Cloud» widget—it’s a class that runs queries about users in WordPress.

Let’s see what WordPress Codex says about the WP_User_Query class:

WP_User_Query is a class, defined in wp-includes/user.php , that allows querying WordPress database tables ‘ wp_users ‘ and ‘ wp_usermeta ‘. This class was introduced in Version 3.1 and as a result, the WP_User_Search class got deprecated.

In essence, we can say that » WP_User_Query is WP_Query for users». It works with wp_users and wp_usermeta to query users and their metadata.

Now, let’s see what’s under the hood and learn about WP_User_Query ‘s properties, methods and parameters. Then we’ll see how it works by going through a few examples.

Quick Tip: We’ve covered this while introducing the properties and methods of the WP_Query class, but let me say it again as a quick reminder: «Properties» and «methods» are merely «variables» and «functions» that are defined inside a PHP class.

Properties of WP_User_Query

There are only seven properties to learn about in the WP_User_Query class. Remember: These should NOT be used to change their values. You can fetch their values, but it’s better not to alter them.

$query_vars

This property stores an associative array of query variables and their values.

$results

This property has the number of found items (users in this case) for the query.

$query_fields

This property, similar to the following properties, stores the SQL clauses for the return fields.

$query_from

This property stores the FROM clause for the query.

$query_where

This property stores the WHERE clause for the query.

$query_orderby

This property stores the ORDERBY clause for the query and is used to order the list of users returned.

$query_limit

This property stores the LIMIT clause for the query and is used to limit the number of users returned.

Methods of WP_User_Query

Remember the methods of the WP_Query class? Well, this class has only four methods and they work just like the methods of WP_Query . Let’s quickly see why each one exists.

The get() Method

This method simply fetches a query variable from the query.

The set() Method

Contrary to the one above, this method sets a query variable instead of getting it.

The get_results() Method

Unlike WP_Query , the WP_User_Query class doesn’t work with a «loop». Instead, you need to use the get_results() method to get the query results and work on them.

The get_total() Method

This little method returns the total number of items (users) for the query.

Parameters of WP_User_Query

Like the WP_Query class, WP_User_Query has parameters that you need to know about. But while WP_Query has a large number of parameters (more than 50!), WP_User_Query has only 17 parameters to worry about—and they’re very similar to the ones in WP_Query , so if you’re familiar with those, it shouldn’t be any hassle learning these ones.

  • blog_id : An integer to specify a blog’s ID in multisite networks. Defaults to the current blog.
  • role : A string to state a user role. Accepts subscriber , author , contributor , author , editor , administrator , and any custom-created user role.
  • include : An array of user IDs to include in the query.
  • exclude : An array of user IDs to exclude from the query.
  • search : A string value to search for in the fields of the wp_users table.
  • search_columns : An array of columns of the wp_users table. Accepts ID , user_login , user_url , user_email , and user_nicename .
  • orderby : A string to state how to sort the returned users. Accepts ID , display_name , name / user_name , login / user_login , nicename / user_nicename , email / user_email , url / user_url , registered / user_registered , post_count , and meta_value . Defaults to login .
  • order : A string to set the order to ascending ( ASC ) or descending ( DESC ).
  • offset : An integer to specify the number of users to pass over.
  • number : An integer to set the number of users to return.
  • count_total : A boolean ( TRUE / FALSE ) to state whether to count the total number of users found.
  • fields : A string or array to decide which fields to return from the wp_users table.
  • who : A string (either authors or all , which is the default value) to state which users to query.
  • meta_key : A string to state a custom user meta field key.
  • meta_value : A string to state a custom user meta field value.
  • meta_compare : A string to set an operator to test the ‘meta_value’ parameter. Accepts ‘=’ , ‘!=’ , ‘>’ , ‘>=’ , ‘ , ‘ , ‘LIKE’ , ‘NOT LIKE’ , ‘IN’ , ‘NOT IN’ , ‘BETWEEN’ , ‘NOT BETWEEN’ , ‘EXISTS’ , and ‘NOT EXISTS’ . Defaults to ‘=’ .
  • meta_query : An array to create a full meta data query, using keys similar to the ones above:
    • key : A string to set a custom field key.
    • value : A string or an array to set a custom field value (or values).
    • compare : A string to set the compare operator. Accepts the same values as meta_compare above.
    • type : A string to set the custom field type. Accepts NUMERIC , BINARY , CHAR , DATE , DATETIME , DECIMAL , SIGNED , TIME , and UNSIGNED . Defaults to CHAR .
Топ-пост этого месяца:  PHP-МАСТЕР. От теории до собственной CMS интернет-магазина

Trying Out WP_User_Query With a Few Examples

Now we’ve seen how WP_User_Query works, let’s do a couple of examples to learn how to use it.

Listing All Editors Except Lisa

Let’s say you want to list your editors to your readers, but you remember that one of your editors, Lisa, has agreed to work with you on condition of anonymity, so you need to leave her out in the «Editors» list. Here’s how you construct the query:

Search for Gmail Users Among Your Authors

Let’s say you want to collect email addresses of your authors which use a Gmail address. Here’s what you do:

Wrapping Everything Up

As you can see, there are just a few differences between WP_Query and WP_User_Query , and the differences actually make WP_User_Query easier to understand. I hope I helped you learn about this neat class of WordPress.

Do you have anything to add to this article? Share your thoughts with us in the Comments section below. And if you liked the article, don’t forget to share it with your friends.

See you in the next part of the series!

If you’re interested in a few scripts and plugins that can give you more advanced functionality with user and membership systems, there’s a useful collection of items of membership scripts on Envato Market.

8 полезных приёмов для базы данных WordPress

Надо отдать должное WordPress. Это действительно потрясающая система для построения блогов и даже полноценных сайтов. Симпатичная и логичная админка (особенно в версиях 2.7 и выше, вкусняшка), немалое количество достаточно качественных шаблонов… да и вообще всё очень приятно и относительно просто. Хочу воздать этой системе должное и сделать для её пользователей что-нибудь полезное.

За последние 10 лет MySQL стала невероятно популярна в сети. Каждый блог WordPress имеет в своей основе именно базу MySQL, в которой хранятся все ваши записи, настройки, комментарии и многое другое.

Хотя плагины и даже, так называемые, хаки (предпочитаю «вставки кода») могут решить некоторые задачи, иногда у вас нет иного выбора, кроме как вводить SQL-запросы в phpMyAdmin или напрямую в базу через SSH. Так что давайте посмотрим на 8 полезных приёмов для базы данных WordPress.

1. Создание бэкапа вашей базы

Проблема. Хотя советы в этой статье были проверены, вам не стоит их применять на практике до создания резервной копии вашей базы MySQL (мало ли что. )

Решение. Чтобы создать вручную резервную копию вашей базы, следуйте за этими простыми шагами:

1. Для начала надо залогиниться в phpMyAdmin и выбрать там свою базу WordPress.

2. Кликните на кнопке «Экспорт» (Export), которая находится в горизонтальном меню.

3. Выберите метод сжатия данных (лично я использую gzip) и нажмите на кнопочку «Пошёл» (Execute).

4. Ваш браузер спросит хотите ли вы скачать бэкап. Разумеется скажите ему твёрдое Да и сохраните файл куда-нибудь на свой компьютер.

Примечание. Учтите, что создание резервных копий базы WordPress гораздо удобнее делать с помощью специального плагина WP-DB-Backup. Пользователи WordPress могут не задумываясь, прямо сейчас установить себе этот плагин если по каким-то причинам всё ещё этого не сделали.

2. Пакетное удаление ревизий записей

Проблема. Ревизии записей — это новая фишка WordPress начиная с версии 2.6. Она может быть очень полезной, а может также увеличить размер базы MySQL. Разумеется, вы можете вручную удалять ревизии постов с админки. Но это очень долго и нудно. Есть решение получше.

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

1. Надо залогиниться в phpMyAdmin и выбрать там свою базу WordPress.

2. Потом нажать на кнопочку «SQL». Появится окошко, в которое надо вставить следующий запрос:

DELETE FROM wp_posts WHERE post_type = «revision»;

3. Вот и всё! В зависимости от количества записей, вы сэкономили кучу драгоценного времени и почистили базу.

Объяснение кода. В таблице wp_posts есть поле под названием post_type. Это поле может иметь множество значений, таких как post, page или revision. Когда мы хотим избавиться от ревизий записей, то просто запускаем команду, чтобы та удалила все значения в таблице wp_posts, в поле post_type которой стоит значение revision. Вот как.

3. Удаляем 5000 спаммерских комментариев за одну секунду

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

Когда он вернулся домой и заглянул в свой блог… то увидел больше 5000 сообщений, которые ожидали модерации! Как быть?

Решение. К своему счастью, мой друг рассказал мне о своей проблеме с долбаными спамерами. Он уже успел потратить 45 минут на ручную проверку и удаление спама, как я показал ему очень полезный трюк:

1. Логинимся в phpMyAdmin и выбираем там свою базу WordPress.

2. Нажимаем на кнопочку «SQL». Появится окошко, в которое надо вставить следующий запрос:

DELETE from wp_comments WHERE comment_approved = ‘0’;

3. И прощайте спамеры! Наслаждаемся чистотой и уютом…

Объяснение. В таблице wp_comments содержится поле comment_approved, в котором хранится булевое значение (1 или 0). Утверждённые комментарии имеют значение 1, а комментарии, которые ожидают модерации — 0. Вышеуказанная команда просто удаляет неутверждённые комментарии. Всё просто.

Но будьте осторожными! Хотя это решение офигенно удобное для автоматического удаления миллионов спамерских комментариев, но оно также удаляет и нормальные неутверждённые комментарии. Если вы всё ещё не используете плагин вроде Akismet, то самое время начать, чтобы предотвратить заспамление блога.

4. Как изменить атрибут записи

Проблема. Когда вы устанавливаете WordPress, создаётся аккаунт «admin» по-умолчанию. Некоторые блоггеры делают ошибку, используя этот аккаунт для создания своих записей, пока они не понимают, что это как-то безлико.

Решение. Модификация атрибута автора для каждой записи занимает туеву хучу времени. К счастью, SQL может нам помочь:

1. Логинимся в phpMyAdmin и выбираем там свою базу WordPress.

2. Для начала нам надо определить правильные ID пользователей. Так что нажимаем на кнопочку «SQL». Появится окошко, в которое надо вставить следующий запрос:

SELECT ID, display_name FROM wp_users;

3. phpMyAdmin отобразит список «айдишников», которые привязаны к пользователям WordPress. К слову, NEW_AUTHOR_ID это ID самого свежесозданного автора, а OLD_AUTHOR_ID это ID оригинального админского аккаунта.

4. После того как вы определили «айдишники» NEW_AUTHOR_ID и OLD_AUTHOR_ID, выполните следующую команду:

UPDATE wp_posts SET post_author=NEW_AUTHOR_ >

5. Это всё. Все записи, которые были привязаны к аккаунту admin теперь будут собственностью того пользователя, которого вы выбрали.

5. Сброс пароля

Проблема. Чтобы защитить свои блоги, люди часто выбирают сильные пароли, такие как 7*KoF5i8_. Это, конечно, похвально, но все слышали множество историй о том как админы забывают свои пароли 🙂

Решение. Когда вы забываете свой пароль, WordPress может отправить вам ссылку для его сброса на email. Но если у вас нет доступа к мылу, которое указано в базе WordPress, или если вы считаете, что вопрос можно решить как-то иначе, то вот вам способ «взлома»:

1. Логинимся в phpMyAdmin, выбираем там свою базу WordPress и открываем окно SQL.

2. Вводим следующую команду (с учётом, что вашим логином был «admin»):

UPDATE ‘wp_users’ SET ‘user_pass’ = MD5(‘PASSWORD’) WHERE ‘wp_users’.’user_login’ = ‘admin’ LIMIT 1;

3. Ну вот, собственно, и всё. Ваш пароль успешно обновится на тот, что вы указали в месте, помеченном как «PASSWORD».

Объяснение. Пароли пользователей хранятся в таблице wp_users. Разумеется используется хэш MD5, чтобы защитить их от просмотра.

Мы отправили SQL-запрос «UPDATE» и использовали встроенную функцию MySQL — MD5(), чтобы конвертировать наш пароль в MD5 и обновить его. Использование «WHERE» гарантирует, что мы обновили только пароль администратора. Тот же запрос, но без использования параметра «WHERE» обновит все пароли в базе!

6. Изменение вашего доменного имени

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

Решение.

1. Как вы уже могли догадаться: логинимся в phpMyAdmin, выбираем там свою базу WordPress и открываем окно SQL

2. Чтобы изменить URL Вордпресса, запускаем вот такую команду:

UPDATE wp_options SET option_value = replace(option_value, ‘http://www.oldsite.com’, ‘http://www.newsite.com’) WHERE option_name = ‘home’ OR option_name = ‘siteurl’;

3. Потом нам нужно заменить относительный URL (GUID) для каждой записи. Следующая команда сделает это за вас:

UPDATE wp_posts SET gu );

4. Это почти конец. Осталось только найти и заменить абсолютные URL в таблице wp_posts table для убедительного финала:

UPDATE wp_posts SET post_content = replace(post_content, ‘http://www.oldsite.com’, ‘http://www.newsite.com’);

5. А вот это уже конец. Можете зайти в админку своего блога используя новый урл.

7. Отображение количества SQL-запросов вашего блога.

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

Решение. Прикол: нам не надо заходить в phpMyAdmin 🙂 Надо только открыть на редактирование файл footer.php (он точно есть в вашей теме) и добавить туда вот такие строки кода:

Топ-пост этого месяца:  Публикация статей в Wordpress как опубликовать пост на сайте

запросов за секунд.

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

Примечание. Сложилось впечатление, что многие пользователи WordPress не в курсе это чудесной возможности. Функция get_num_queries() возвращает количество созданных запросов во время загрузки страницы.

Учтите, что код, приведённый выше, отображает количество запросов только залогиненым пользователям, так как гости блога и поисковые боты не обязаны знать эту информацию. Но вы можете сделать отображение публичным, просто убрав условный оператор if (is_user_logged_in()) с кода.

8. Восстановление вашей базы данных

Проблема. Скажем… по некоторым причинам, таким как взлом или проблема с обновлением, вы можете потерять данные вашего блога или обнаружить их безнадёжно испорченными. Так что если у вас есть резервная копия (правда же есть, да?), вам необходимо импортировать её в свою базу Вордпресса. И тогда всё будет хорошо. Скорее всего.

Решение.

1. Логинимся в phpMyAdmin, выбираем там свою базу WordPress.

2. Жмём на кнопку «Импорт» (Import) в горизонтальном меню.

3. Нажмите кнопку «Открыть» (Browse) и выберите самую свежую копию базы со своего диска.

4. Жмём на кнопку «Пошёл» (Execute). Если всё пройдёт удачно и боги на вашей стороне, база данных будет снова полностью функциональна.

Этот пост — вольный перевод статьи 8 Useful WordPress SQL Hacks. Спасибо Jean-Baptiste Jung’у, автору оригинала. Пост рассчитан на новичков WordPress и я надеюсь, что рекомендации кому-нибудь пригодятся.

Working with the WordPress user meta query

The WordPress user meta query is a great tool for user search and segmentation. It allows us to go beyond the simple searches by username or email. With this coding tool, we’re able to retrieve users by using the WordPress meta query for any custom fields they have. Additionally, it’s possible to combine different search criteria and gather the exact information we need.

If you want to search your users, you need to get your hands dirty with the WordPress user meta query, the WP_User_Query . WP_User_Query is a PHP class for direct database search. Although it may seem complex at first, it’s very powerful when mastered. And that’s our goal today, to master the basic elements of the WordPress user meta query for custom field searches.

And although the coding path is great, we have other options. It’s possible to use plugins to greatly simplify our user search tasks. Therefore, we can use plugins such as Users Insights, to filter users based on their custom fields. It works like the WordPress meta query, but it’s a much easier approach.

Now let’s get started and play with the WordPress user query options.

Using custom fields in a WordPress User Query

Don’t be afraid if you don’t know how to code. These are just simple examples, and we go through some coding-free options afterward. But for now, we walk through how the WordPress meta query works when we are filtering users. In order to follow along, we advise you create a child theme.

Let’s get familiarized with beloved WP_User_Query class. Its inner workings are very similar to the posts query, the WP_Query. This is its basic syntax:

Rcl_Query — удобный класс для построения запросов к БД от WP-Recall

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

  • добавление данных,
  • их обновление или изменение,
  • удаление,
  • а также их получение.

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

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

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

Шестнадцатая версия плагина WP-Recall, кроме всего прочего, получила в ядро новый класс Rcl_Query, который позволил перевести почти все запросы к БД на получение данных на себя, сформировав, таким образом, рекомендуемый стандарт, которым очень удобно пользоваться. Рассмотрим подробнее порядок работы с новым классом и прикинем его возможности для применения в наших будущих разработках к плагину WP-Recall.

Внимание! Для того, чтобы читать и понимать суть написанного ниже, вы должны иметь представление о работе с классом wpdb и уметь строить SQL-запросы к базе данных.

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

Для примера работы будем рассматривать не абы какую, а вполне настоящую таблицу, которая использует в дополнении групп, со следующей структурой:

pre_user_query tutorial: hiding the user with the exact ID, hiding the users by the role, extending the user search

First of all you should know one important moment. There are two base user query action hooks: pre_get_users — it fires before WP_User_Query has been parsed and allows you to change some query vars like include, exclude, order, orderby etc. pre_user_query fires after the user query has been parsed but before the query is executed. […]

First of all you should know one important moment. There are two base user query action hooks:

  1. pre_get_users — it fires before WP_User_Query has been parsed and allows you to change some query vars like include , exclude , order , orderby etc.
  2. pre_user_query fires after the user query has been parsed but before the query is executed. Do you see the difference?

Let’s begin with the base example, just copy the following code to your current theme functions.php file and open a page with the user list. It can be your administration «Users» page.

I hope you already know what print_r() function is.

And one more thing, if your WordPress version is lower that 3.1, the following examples won’t work for you (try to use pre_user_search instead or update your WordPress).

1. How to completely hide the user with the exact ID from your website.

Okay, this user will not be displayed on the website or inside administration area at all. How to archieve it? With the help of pre_user_query of course.

  • You can move the if condition outs >

Do not worry about that — there are plenty of filters that can help you.

2. How to remove the ability for other users to view administrators in user lists?

It is the more interesting example than the previous one, it based on the same principle, but you can see the complex SQL query in it.

Perhaps you know that user roles are stored in wp_usermeta table (change wp_ to your database prefix) under the wp_capabilities meta_key. So, in the example above we got all the users which has administrator word in their wp_capabilities values.

3. Extend the user search by custom meta_keys from wp_usermeta or custom columns from the other tables.

By default WordPress allows to search users by predefined columns ( user_login , user_email , user_url , display_name , ID and user_nicename ). You can also use the user_search_columns filter to exclude some of the predefined columns from the search.

But pre_user_query allows you to search by a first name, a last name, another user meta key or take wp_posts table for example and search by post titles, this user has been published.

Related Posts

Misha Rudrastyh

I love WordPress, WooCommerce and Gutenberg so much. 10 yrs of experience.

Need some custom developer help? Let me know

Need some help with WordPress?

If you need some professional developer help, I will be happy to assist you.

Comments — 16

Hi Misha, thanks for the good tips and explanations!

About the user counts you say:

— “Do not worry about that — there are plenty of filters that can help you”.

Can you mention what are they?

For example: I like to exclude all users of a role in this count.

Список пользователей по имени в WP_User_Query

Как я могу перечислить пользователей по имени ASC при использовании WP_User_Query ?

Существует параметр orderby, но, глядя в основном, он не принимает заказы на мой пользовательский мета. Кто-нибудь знает, как расширить WP, чтобы разрешить этот заказ по фамилии?

Solutions Collecting From Web of «Список пользователей по имени в WP_User_Query»

Существует лучший способ сделать это с WordPress версии 3.7. Используйте свойство meta_key WordPress, чтобы выбрать свойство последнего имени, а затем orderby => meta_value с восходящим порядком.

Сделал что-то сам:

Файл шаблона страницы:

Просто вам известно, что я использую альфа-версию WP-PageNavi, которая поддерживает разбиение на страницы для WP_User_Query. Вышеизложенное касается только макета и разбивки на страницы. Ниже приведена магия:

Файл functions.php:

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

Добавить комментарий