Wie frage ich Beiträge nach Teilmetaschlüsseln ab?

Es ist ziemlich schwierig, Ihre Frage konkret zu beantworten. Der erste Teil ist jedoch einfach. Ich habe vor kurzem etwas gemacht ähnlich wie bei stackoverflow

Metaschlüssel werden verglichen und stimmen genau überein. WP_Query hat keine Möglichkeit, dieses Verhalten mit einem einfachen Parameter anzupassen. Wir können uns jedoch jederzeit einen vorstellen und dann die posts_where-Klausel anpassen, um einen LIKE-Vergleich für Metaschlüssel durchzuführen.

DER FILTER

Dies ist nur ein grundlegender Filter, passen Sie ihn nach Bedarf an.

add_filter( 'posts_where', function ( $where, \WP_Query $q )
{ 
    // Check for our custom query var
    if ( true !== $q->get( 'wildcard_on_key' ) )
        return $where;

    // Lets filter the clause
    $where = str_replace( 'meta_key =', 'meta_key LIKE', $where );

    return $where;
}, 10, 2 );

Wie Sie sehen, wird der Filter nur ausgelöst, wenn wir unseren neuen benutzerdefinierten Parameter wildcard_on_key auf true setzen. Wenn dies auscheckt, ändern wir einfach den =-Komparator in den LIKE-Komparator

Nur eine Anmerkung dazu: LIKE Vergleiche sind von Natur aus teurer als andere Vergleiche

DIE ABFRAGE

Sie können Ihre Beiträge einfach wie folgt abfragen, um alle Beiträge mit Metaschlüsseln zu erhalten. like_status_{user_id}

$args = [
    'wildcard_on_key' => true,
    'meta_query'      => [
        [
            'key'   => 'like_status_',
            'value' => 1,
        ]
    ]
];
$query = new WP_Query( $args );

ANDERE FRAGE

Benutzerdefinierte Felder haben keinen Einfluss auf die Leistung. Sie können meinen Beitrag zu diesem Thema lesen hier . Ich bin jedoch beunruhigt darüber, dass Sie sagen, dass jeder Beitrag Hunderte oder Tausende von Likes haben kann. Dies kann sich negativ auf das Abrufen und Zwischenspeichern einer so großen Menge benutzerdefinierter Felddaten auswirken. Es kann auch Ihre Datenbank mit einer großen Menge an unnötigen benutzerdefinierten Felddaten verstopfen, was die Wartung ziemlich schwierig macht.

Ich bin kein großer Fan von Speichern serialisierter Daten in benutzerdefinierten Feldern, da nach serialisierten Daten nicht gesucht oder bestellt werden kann. Ich würde jedoch vorschlagen, alle Benutzer-IDs in einem Array unter einem benutzerdefinierten Feld zu speichern. Sie können das Array einfach mit der Benutzer-ID aktualisieren, wenn ein Benutzer einen Beitrag mag. Das Abrufen der benutzerdefinierten Felddaten und das Durchlaufen des Arrays von IDs und das Ausführen von Aktionen mit den IDs sind einfach. Schauen Sie sich einfach get_post_meta() an.

Das Aktualisieren eines benutzerdefinierten Felds ist ebenfalls einfach. Dazu müssen Sie sich mit update_post_meta() befassen. Ich weiß nicht, wie Sie Ihre benutzerdefinierten Felder erstellen, aber update_post_meta() ist definitiv etwas, das Sie verwenden möchten.

Wenn Sie E-Mails oder Push-Benachrichtigungen senden müssen, wenn ein benutzerdefiniertes Feld aktualisiert wird, können Sie mit den folgenden Hooks arbeiten. ( Siehe update_metadata() für den Kontext )

• update_postmeta

• _ {$ meta_type} _meta aktualisiert

• updated_postmeta

• _ {$ meta_type} _meta aktualisieren

• _ {$ meta_type} _metadata aktualisieren

FAZIT

Bevor ich dies wieder veröffentliche, stellen Sie sicher, dass Sie nicht nach den sortierten Daten sortieren oder nach bestimmten Daten in den serialisierten Daten suchen müssen, bevor Sie die serialisierte Route gehen.

Wenn Sie dies später mit detaillierteren Statistiken, Funktionen usw. erweitern möchten, könnte eine weitere Alternative sein: benutzerdefinierte Tabelle (n)

• Profis : Auf Ihre Bedürfnisse zugeschnitten und können indexiert werden, um eine bessere Leistung zu erzielen.

• cons : Mehr Arbeit

Möglicherweise gibt es auch eine Problemumgehung mit einer benutzerdefinierten Taxonomie, die aufgrund der Indizierung der Kerntabellen eine bessere Abfrageleistung bietet als Post-Meta-Abfragen.

Ich versuche, eine Benachrichtigung an alle zu senden, denen ein Beitrag gefallen hat, wenn jemand anderem dieser Beitrag gefällt ... so etwas wie "Hey, jemand anderem hat dieser Beitrag gefallen, den Sie gefallen haben. Sie sollten ihn sich ansehen!" Aber ich brauche einen Weg, um herauszufinden, ob jemandem dieser Beitrag gefallen hat und wenn ja, wer er wäre, könnte ich ihn benachrichtigen.

Nicht sicher, welche Art von Benachrichtigungen Sie hier meinen, aber dies kann schnell unhandlich werden.

Beispiel : Ein Benutzer, der ~ 1000 Posts mag und jeder Post ~ 1000 Likes bekommt, dann gibt es 1 Million Benachrichtigungen in den Pipes, nur für diesen Benutzer! Wenn dies E-Mail-Benachrichtigungen sind, ist der Host-Anbieter möglicherweise nicht zufrieden und der Benutzer wird verrückt. Dies kann auch bei einem E-Mail-Dienst eines Drittanbieters teuer sein.

Seit WordPress 5.1 ist es nun möglich, Meta-Abfragen wie die folgenden zu verwenden: 

In der WP_Meta_Query Dokumentation können Sie das Argument compare im Argument meta_query von WP_Query verwenden. Sie können jedoch nur die value und nicht die key vergleichen, sodass Sie möglicherweise überdenken möchten, wie Sie dies strukturieren.

Ein like Argument würde so aussehen:

$arguments = array(
    'meta_query' => array(
        array(
            'key' => 'foo',
            'value' => 'ba',
            'compare' => 'LIKE'
        )
    )
);

$query = new WP_Query($arguments);

Da Sie in der key keine 'LIKE'-Suche durchführen können, empfehlen wir Ihnen, die gewünschten Beiträge in das Benutzer-Meta aufzunehmen und eine WP_User_Query -Suche nach Benutzern durchzuführen, denen dieser Beitrag gefallen hat:

$arguments = array(
    'meta_query' => array(
        array(
            'key' => 'liked_post',
            'value' => '<post_id>'
        )
    )
);

$users = new WP_User_Query($arguments);