Mestring av wp_User_Query: Bygg EN skalerbar medlemskatalog i WordPress

I WordPress-økosystemet får WP_Query all æren, men WP_User_Query styrer verdenen av medlemsnettsteder, intranett og fellesskapsplattformer.

Enten du bygger en enkel “Vårt team”-side eller en kompleks “Finn en lege”-søkemotor med tusenvis av fagfolk, er det ofte overkill å stole på plugins som Ultimate Member for presentasjonslaget – og det skaper flaskehalser for ytelsen.

I denne guiden hopper vi over GUI-en og bygger effektive, sikre brukerspørringer direkte i PHP. Vi dekker detaljert filtrering, ytelsesbufring og kritiske sikkerhetstiltak for å forhindre datalekkasjer.

1. Development() vs. Wp_User_Query

Akkurat som get_posts() er en wrapper for WP_Query, er development() en forhåndskonfigurert wrapper for WP_User_Query.

• Bruk development() for enkle lister (f.eks. “Vis meg 5 administratorer”). Den returnerer en array av WP_User-objekter.
• Bruk WP_User_Query når du trenger avanserte SQL-manipulasjoner, detaljert ‘orderby’-logikk, eller direkte inspeksjon av spørringshoder/resultater.

For 95% av tilfellene bruker vi argument-arrayen, som gjelder for begge.

2. Grunnleggende: Bygge EN team-side

La oss si at vi vil vise et rutenett av ansatte (Redaktører og Forfattere) sortert etter visningsnavn.

$args = [
    'role__in'    => ['editor', 'author'],
    'orderby'     => 'display_name',
    'order'       => 'ASC',
    'number'      => 12, // Paginering
    'paged'       => 1,
];

$user_query = new WP_User_Query($args);
$results    = $user_query->get_results();

if (!empty($results)) {
    echo '<div class="team-grid">';
    foreach ($results as $user) {
        $avatar = get_avatar($user->ID, 128);
        $name   = esc_html($user->display_name);
        $bio    = esc_html(get_user_meta($user->ID, 'description', true));
        
        echo "<article class='team-member'>
                <figure>{$avatar}</figure>
                <h3>{$name}</h3>
                <p>{$bio}</p>
              </article>";
    }
    echo '</div>';
}

3. Avansert filtrering (meta queries)

Det er her WP_User_Query skinner. Tenk deg at du har en katalog over utviklere og du vil finne de som:

1. Er basert i “Oslo”.
2. Har profilen markert som “Offentlig”.
3. Har “PHP” oppført som ferdighet.

$args = [
    'role'       => 'subscriber',
    'meta_query' => [
        'relation' => 'AND',
        [
            'key'     => 'city',
            'value'   => 'Oslo',
            'compare' => '='
        ],
        [
            'key'     => 'is_public_profile',
            'value'   => '1',
            'compare' => '='
        ],
        [
            'key'     => 'skills',
            'value'   => 'PHP',
            'compare' => 'LIKE' // Tregt, men effektivt for serialiserte arrays
        ]
    ]
];

[!WARNING] Ytelsesvarsel: Spørringer mot wp_usermeta er kostbare. I motsetning til wp_posts, er brukertabeller sjelden optimalt indeksert for kompleks filtrering. For kataloger med >10 000 brukere, vurder å flytte søkeindeksen til Elasticsearch (via ElasticPress) eller bruke egne SQL-tabeller.

4. Ytelsesoptimalisering

Når du spør etter brukere på et nettsted med høy trafikk, må du være sparsom med database-ressursene.

A. Begrens returfeltene (fields)

Som standard henter WordPress hver minste bit med data om brukeren (alle metadata). Hvis du bare trenger navn og e-poster, fortell WordPress at det skal være lett.

$args = [
    'role'   => 'subscriber',
    'number' => 100,
    'fields' => ['ID', 'display_name', 'user_email'], // Returnerer stdClass-objekter, ikke WP_User
];

Resultat: Minnebruken faller drastisk.

B. Tell brukere uten å laste dem

Hvis du bare vil vise “Vi har 500 medlemmer!”, ikke last inn medlemsobjektene.

$args = [
    'role'   => 'subscriber',
    'fields' => 'ID', // Hent kun ID-er
];
$query = new WP_User_Query($args);
$count = $query->get_total(); // Bruker SQL_CALC_FOUND_ROWS logikk

Eller for ekstrem hastighet (uten komplekse filtre), bruk count_users():

$count = count_users();
echo "Vi har " . $count['total_users'] . " brukere.";

5. Sikkerhet: “User enumeration”-trusselen

Som standard er WordPress ganske “lekk” når det gjelder brukerdata.

1. Ikke vis Påloggingsnavn: Aldri utfør echo $user->user_login. Dette er halvparten av nøkkelen som trengs for å hacke en admin-konto. Bruk alltid display_name eller user_nicename.
2. Skjul E-poster: Med mindre det er et internt intranett, aldri skriv ut user_email i HTML-koden for å unngå spam-boter.

Blokkering av forfatterarkiver

Hackere skanner ofte /?author=1, /?author=2 for å oppdage brukernavn. Hvis du bygger et firmanettsted der brukere ikke trenger offentlige arkiver, deaktiver denne ruten.

// Legg til i functions.php
add_action('template_redirect', function() {
    if (is_author()) {
        wp_redirect(home_url(), 301);
        exit;
    }
});

6. Oppsummering

Å bygge en egen medlemskatalog gir deg full kontroll over ytelse og sikkerhet.

1. Bruk fields-parameteren for å redusere minneavtrykket.
2. Cache resultatene ved hjelp av Transients API hvis katalogen ikke endres hver time.
3. Rens utdataene nådeløst (alltid esc_html).
4. Beskytt personvernet ved å skjule pålogginger og e-poster.

Brukere i WordPress er entiteter akkurat som innlegg – begynn å spørre etter dem med samme presisjon.