Ich versuche abzufragen, wie oft jeder Datensatz in einer Spalte in meiner Tabelle aus der Datenbank in WordPress vorhanden ist, und diese Spalte zu exportieren. Wie würde ich das tun?
In dem exportierten Excel möchte ich die Spalte von meta_value mit meta_key “user_valid” und eine Spalte mit der Anzahl haben, wie oft dieser meta_value in der mysql-Spalte vorhanden ist.
meta_key meta_value
user_valid '1, 2, 3'
user_valid '1, 2, 1'
user_valid '1, 2, 3'
Für den Export der Spalte ‘meta_value’ mit dem meta_key ‘user_valid’ habe ich verwendet:
SELECT meta_value FROM `us_test` WHERE meta_key = 'user_valid'
Und ich exportiere mit der Export-Schaltfläche aus MYSQL, nachdem ich diese Abfrage verwendet habe.
Ich weiß nicht, wie ich die Abfrage für die andere Spalte durchführen soll.
Ich denke, es sollte ungefähr so sein, aber ich bin mir nicht sicher, denn wenn ich die nächste Abfrage verwende, werden nicht alle Datensätze zurückgegeben:
SELECT meta_value, COUNT( * ) c FROM `us_test` WHERE meta_key = 'user_valid' GROUP BY meta_value
Sie haben hier zwei Möglichkeiten, den WordPress-Weg und den anderen Weg, SQL.
Kurz bevor ich anfange, sollten Sie niemals einen DB-Namen hartcodieren, das Problem ist, dass Sie den DB-Namen in allen Abfragen ändern müssten, bei denen es sich um einen Hardcode handelt, wenn Sie den Code auf eine andere Website mit einem anderen DB-Namen verschieben, auch wenn Sie Ändern Sie den DB-Namen auf der Website, an der Sie arbeiten. Dies kann Sie auf eine wilde Gänsejagd bringen, sollten Sie das vergessen
Du solltest Eingabedaten immer bereinigen und validieren um sicherzustellen, dass kein bösartiger Code in Ihre Website eingeschleust wird. SQL-Injection ist weit verbreitet und viele Hacker verwenden SQL-Injection, um eine Website zu hacken
SQL
SQL gibt einem etwas weniger Kontrolle, da es weniger dynamisch ist. Wenn Sie beispielsweise nur eine Zählung für einen bestimmten Begriff benötigen, müssen Sie die Abfrage direkt ändern oder eine Art Filtersystem implementieren.
Wie ich bereits gesagt habe, sollten Sie DB-Namen niemals fest codieren, sondern die wpdb-Klasse verwenden, um das Präfix festzulegen. Dadurch werden Probleme in Zukunft vermieden. Außerdem müssen Sie, wie gesagt, bereinigen, um eine SQL-Einschleusung zu vermeiden. In diesem Fall verwenden wir die prepare
-Methode der wpdb-Klasse, um sich um die Bereinigung zu kümmern und vor SQL-Injection zu schützen.
Hier ist die Funktion, die ich hier und da kommentiert habe, um Sinn zu machen:
function get_post_meta_key_count( $key = '', $value="", $type="post", $status="publish" )
{
// Use $wpdb to avoid bugs and errors, do not hardcode db names
global $wpdb;
if( empty( $key ) )
return;
// Set the default WHERE clause where we return the count of the key regardless of value
$where = $wpdb->prepare(
"
pm.meta_key = '%s'
AND p.post_type="%s"
AND p.post_status="%s"
",
$key,
$type,
$status
);
// If a value is specified, add that to the WHERE clause
if ( $value ) {
$where .= $wpdb->prepare(
"
AND pm.meta_value="%s"
",
$value
);
}
// Query the db to return the post count according to key and value if value is set
$count = $wpdb->get_var(
"
SELECT count(DISTINCT pm.post_id)
FROM {$wpdb->postmeta} pm
JOIN {$wpdb->posts} p ON (p.ID = pm.post_id)
WHERE {$where}
"
);
return $count;
}
Was ich hier getan habe, ist, ich habe einen Parameter gesetzt, wenn Sie jemals die Anzahl eines bestimmten Metawerts eines bestimmten Metaschlüssels erhalten müssen.
VERWENDUNGSZWECK
Sie können die Funktion nun wie folgt verwenden:
-
echo get_post_meta_key_count( 'my_key' );
für Beitragsanzahl von meta_key
my_key
für den Standard-Beitragstyp post
und nur veröffentlichte Beiträge
-
echo get_post_meta_key_count( 'my_key', '', 'custom_post_type', 'trash' );
für Beitragsanzahl von meta_key
my_key
für den benutzerdefinierten Beitragstyp custom_post_type
und nur verworfene Beiträge
-
echo get_post_meta_key_count( 'my_key', 'my_value' );
für Beitragsanzahl von meta_key
my_key
und für die meta_value
, my_value
für den Standard-Beitragstyp post
und nur veröffentlichte Beiträge
WP_Query
Wenn Sie nach einer Möglichkeit suchen, dies zu tun (was immer Ihre erste Option sein sollte), du kannst den … benutzen WP_Query
Klasse dazu.
Das Problem mit der Verwendung WP_Query
ist, dass es sehr teuer werden kann, wenn es nicht richtig verwendet wird. Viele Menschen meiden WP_Query
aus diesem Grund oder führt unwissentlich Abfragen aus, die ziemlich teuer und unnötig sind. Wir werden also nach einer Möglichkeit suchen, dies so schnell wie eine benutzerdefinierte SQL-Abfrage zu machen.
Der eigentliche Vorteil von WP_Query
Oben eine benutzerdefinierte SQL-Abfrage ist, können Sie die Abfrage anpassen, indem Sie einfach die erforderlichen Parameter übergeben. WP_Query
wird sich immer um die harte Arbeit kümmern, die richtige SQL-Abfrage gemäß den übergebenen Parametern zu erstellen.
Schauen wir uns die Optimierung an WP_Query
um nur einen Beitragszähler zurückzugeben
-
Erstens werden wir nur einen einzigen Beitrag abfragen. WP_Query
ist standardmäßig so aufgebaut, dass egal wie viele Beiträge abgefragt werden (1, 100 oder alle Beiträge), WP_Query
werde weiter suchen alle Beiträge, die der Abfrage entsprechen, obwohl die abgefragte Menge an Beiträgen bereits gefunden und zurückgegeben wurde. Der Grund dafür ist die Paginierung. Um die Paginierung korrekt zu berechnen, WP_Query
muss wissen, wie viele Posts es gibt, die der Abfrage entsprechen.
So WP_Query
weiterhin die Datenbank durchsuchen, nachdem die Anzahl der abgefragten Posts zurückgegeben wurde, um alle Posts zu zählen, die der Abfrage entsprechen. Diese Beitragsanzahl wird in der gespeichert $found_posts
Eigenschaft der Abfrage, und es ist diese Zahl, die in Verbindung mit verwendet wird posts_per_page
die verwendet wird, um zu berechnen, wie viele Seiten es geben würde.
Dies funktioniert nicht für get_posts
obwohl get_posts
Verwendet WP_Query
. get_posts
geht vorbei 'no_found_rows' => true
zu WP_Query
die die Abfrage abbricht, sobald die Anzahl der abgefragten Beiträge gefunden wird. Dies bricht rechtlich die Paginierung, deshalb get_posts
sind so große Kopfschmerzen, richtig zu paginieren
-
Zweitens werden wir nur die ID des einzelnen Beitrags abfragen, die wir abfragen müssen, nicht die vollständige WP_Post
Objekt. Das spart Abfragezeit.
Schauen wir uns also diese Funktion an:
function get_post_meta_key_count( $key = '', $value="", $args = [] )
{
// If the $key value is empty, bail
if( empty( $key ) )
return;
// Set the defaults and override any value set for the specific default
$args['posts_per_page'] = 1;
$args['fields'] = 'ids';
if ( $value ) {
$args['meta_query'][] = [
'key' => $key,
'value' => $value
];
} else {
$args['meta_query'][] = [
'key' => $key,
];
}
$q = new WP_Query( $args );
// Return the post count
return $q->found_posts;
}
VERWENDUNGSZWECK
WP_Query
verwendet standardmäßig die post
Posttyp und publish
als Beitragsstatus, sodass wir dies für normal veröffentlichte Beiträge nicht festlegen müssen. Ich habe hier einen dritten Parameter mit dem Namen eingefügt $args
akzeptiert dieser Parameter genau dieselben Parameter wie die WP_Query
Klasse, da diese alle direkt weitergegeben werden WP_Query
. Sie können hier also beliebige Parameter hinzufügen, um eine Zählung von einem bestimmten Metaschlüssel oder Wert zu erhalten
-
echo get_post_meta_key_count( 'my_key' );
für Beitragsanzahl von meta_key
my_key
für den Standard-Beitragstyp post
und nur veröffentlichte Beiträge
-
echo get_post_meta_key_count( 'my_key', 'my_value' );
für Beitragsanzahl von meta_key
my_key
und für die meta_value
, my_value
für den Standard-Beitragstyp post
und nur veröffentlichte Beiträge
-
echo get_post_meta_key_count( 'my_key', 'my_value', ['post_type'=>'cpt', 'cat'=>1] );
für Beitragsanzahl von meta_key
my_key
und für die meta_value
, my_value
für den benutzerdefinierten Beitragstyp cpt
und nur veröffentlichte Beiträge aus der Kategorie ID 1
LEISTUNGSPRÜFUNG EIN meta_key
mit 24 Beiträgen
-
SQL -> 1 Abfrage in +/- 0,005 Sekunden
-
WP_Query
-> 2 Abfragen in +/- 0,012 Sekunden
Wie Sie sehen können, gibt es einen winzigen Unterschied in der Leistung, also die WP_Query
-Methode ist hier mit Sicherheit die beste Option, da sie viel dynamischer ist, wenn auch nur ein bisschen langsamer
Also beantworte ich meine eigene Frage:
Die Abfrage aus meiner Frage ist absolut richtig:
SELECT meta_value, COUNT( * ) c FROM `us_test` WHERE meta_key = 'user_valid' GROUP BY meta_value
Ich bin verwirrt … geben Sie sich ein Kopfgeld für eine “vorbildliche” Antwort? Oder suchen Sie eine Alternative?
– rnevius
14. November 2015 um 2:46 Uhr
@rnevius Ich denke, OP hat die falsche Prämienerklärung gewählt. Es gibt bessere Möglichkeiten, dies zu tun, also denke ich, dass er Antworten mit diesen Alternativen braucht
– Pieter Goosen
14. November 2015 um 4:19 Uhr