‘s’ Begriff in WP_Query erweiterte class verursacht großen Speicherverlust (268MB)

Ich habe WP-Geo-Posts als Ausgangspunkt für das Erstellen eines Plugins verwendet, das WooCommerce erweitert, um klassifizierungsähnliche functionen zu unterstützen. Mit ACF habe ich Produkte mit einem Standort (Längen- und Breitengrad) verknüpft und baue nun die Standortunterstützung in die Suche ein. Benutzer liefern Suchbegriffe, einen Ort und einen Radius. Ergebnisse sollten Produkte in einem bestimmten Umkreis sein, geordnet nach dem am nächsten gelegenen Standort. Es funktioniert perfekt, aber die Suche ignoriert derzeit alle Suchbegriffe, die der Benutzer eingibt.

Ich habe eine class erstellt, die WP_Query erweitert, um das Pseudofeld von ‘distance’ zu erstellen. Sie würden denken, ich könnte nur s für das gleiche $args Array bereitstellen, und es würde scope nach Schlüsselwort wie WP_Query tun. Stattdessen bekomme ich eine leere Seite und die Logs sagen

  PHP Fatal error: Allowed memory size of 268435456 bytes exhausted (tried to allocate 130968 bytes) in /home/mydir/home/mysite/public_html/wp-includes/query.php on line 1681, referer: http://example.com/shop/ 

Ich habe das, was gut funktioniert:

 $args = array( 'post_type' => $query->get('post_type') , 'posts_per_page' => 20, 'fields' => 'all', 'lat' => $_REQUEST['lat'], 'lng' => $_REQUEST['lng'], 'distance' => $_REQUEST['dist'] ); $query = new WP_Query_Geo( $args ); 

Und das, was Speicher wie Gangster leckt:

 $args = array( 'post_type' => $query->get('post_type') , 'posts_per_page' => 20, 'fields' => 'all', 'lat' => $_REQUEST['lat'], 'lng' => $_REQUEST['lng'], 'distance' => $_REQUEST['dist'], 's' => $search_terms ); $query = new WP_Query_Geo( $args ); 

Meine class, die WP_Query (WP_Query_Geo) erweitert, verwendet concats ( .= ) Für $ -Felder, $ join und $, also sehe ich nicht, warum die Angabe von s Schaden anrichten sollte.

Dies ist die Ausgabe von var_dump($query->request); ohne die s in $ args:

 string(799) "SELECT SQL_CALC_FOUND_ROWS wp_posts.*, ( 6371 * acos( cos( radians(48.4284207) ) * cos( radians( latitude.meta_value ) ) * cos( radians( longitude.meta_value ) - radians(-123.36564440000001) ) + sin( radians(48.4284207) ) * sin( radians( latitude.meta_value ) ) ) ) AS distance , latitude.meta_value AS latitude , longitude.meta_value AS longitude FROM wp_posts INNER JOIN wp_postmeta AS latitude ON wp_posts.ID = latitude.post_id INNER JOIN wp_postmeta AS longitude ON wp_posts.ID = longitude.post_id WHERE 1=1 AND wp_posts.post_type = 'product' AND (wp_posts.post_status = 'publish') AND latitude.meta_key="lat" AND longitude.meta_key="lng" HAVING distance <= 100 ORDER BY distance ASC, wp_posts.post_date DESC LIMIT 0, 20" 

Solutions Collecting From Web of "‘s’ Begriff in WP_Query erweiterte class verursacht großen Speicherverlust (268MB)"

Ich bin nicht sicher, welche Konvention mit pre_get_posts , aber es scheint zu sein, um zusätzliche Argumente zu setzen und nicht zu ersetzen und dann die Abfrage pre_get_posts . Beim Vergleich von wp_query und meiner eigenen Geo-Abfrage bemerkte ich, dass meine eigenen Post-Daten im Abfrage-Objekt hatten. Das mag der Grund für das Speicherleck gewesen sein, aber es muss eine Endlosschleife gehabt haben – meine gesamte DB ist keine wo in der Nähe von 268MB. Vielleicht soll die Abfrage nicht innerhalb des Konstruktors stattfinden? Ich würde gerne eine Lösung mit pre_get_posts .

Anstatt pre_get_posts , habe ich den woocommerce_before_shop_loop Hook verwendet, um $wp_query insgesamt zu ersetzen.

 add_action('woocommerce_before_shop_loop', 'wr_product_geo_query'); function wr_product_geo_query() { global $wp_query; if ($wp_query->is_search() && isset($_REQUEST['loc'])) { $args = array( 'post_type' => $_REQUEST['post_type'] , 'posts_per_page' => 20, 'fields' => 'all', 'lat' => $_REQUEST['lat'], 'lng' => $_REQUEST['lng'], 'distance' => $_REQUEST['dist'], 's' => $_REQUEST['s'] ); $wp_query = new WP_Query_Geo( $args ); } } 

Ziemlich einfach, aber ich hätte gerne eine Lösung, die sich in das Standardsuchverhalten einfügt, anstatt sich auf einen Vorlagen-Hook zu verlassen.

Update: Nach vielen internen Überlegungen glaube ich, dass pre_get_posts ausschließlich dazu dient, eine bestehende Anfrage zu modifizieren. Ich modifiziere es nicht, ich zerstöre es. In diesem Fall ist das Erstellen eines neuen Abfrageobjekts über eine benutzerdefinierte Vorlage oder einen Vorlagen-Hook der “richtige” Weg, dies zu tun.