Ist es eine schlechte Übung, während der Entwicklung eines Plugins direkt zur MySQL-database zu gehen?

Dies ist ein Beispiel für das ” Vote it Up” -Plugin:

//Run this to create an entry for a post in the voting system. Will check if the post exists. If it doesn't, it will create an entry. function SetPost($post_ID) { global $wpdb; //prevents SQL injection $p_ID = $wpdb->escape($post_ID); //Check if entry exists $id_raw = $wpdb->get_var("SELECT ID FROM ".$wpdb->prefix."votes WHERE post='".$p_ID."'"); if ($id_raw != '') { //entry exists, do nothing } else { //entry does not exist $wpdb->query("INSERT INTO ".$wpdb->prefix."votes (post, votes, guests, usersinks, guestsinks) VALUES(".$p_ID.", '', '', '', '') ") or die(mysql_error()); } } //Run this to create an entry for a user in the voting system. Will check if the user exists. If it doesn't, it will create an entry. function SetUser($user_ID) { global $wpdb; //prevents SQL injection $u_ID = $wpdb->escape($user_ID); //Check if entry exists $id_raw = $wpdb->get_var("SELECT ID FROM ".$wpdb->prefix."votes_users WHERE user='".$u_ID."'"); if ($id_raw != '') { //entry exists, do nothing } else { //entry does not exist $wpdb->query("INSERT INTO ".$wpdb->prefix."votes_users (user, votes, sinks) VALUES(".$u_ID.", '', '') ") or die(mysql_error()); } } //Returns the vote count function GetVotes($post_ID, $percent = false) { global $wpdb; //prevents SQL injection $p_ID = $wpdb->escape($post_ID); //Create entries if not existant SetPost($p_ID); //Gets the votes $votes_raw = $wpdb->get_var("SELECT votes FROM ".$wpdb->prefix."votes WHERE post='".$p_ID."'"); $sinks_raw = $wpdb->get_var("SELECT usersinks FROM ".$wpdb->prefix."votes WHERE post='".$p_ID."'"); $guestvotes_raw = $wpdb->get_var("SELECT guests FROM ".$wpdb->prefix."votes WHERE post='".$p_ID."'"); $guestsinks_raw = $wpdb->get_var("SELECT guestsinks FROM ".$wpdb->prefix."votes WHERE post='".$p_ID."'"); /* Deprecated $uservotes_raw = $wpdb->get_var("SELECT votes FROM ".$wpdb->prefix."votes_users WHERE user='".$u_ID."'"); $usersinks_raw = $wpdb->get_var("SELECT sinks FROM ".$wpdb->prefix."votes_users WHERE user='".$u_ID."'"); */ //Put it in array form $votes = explode(",", $votes_raw); $sinks = explode(",", $sinks_raw); $guestvotes = explode(",", $guestvotes_raw); $guestsinks = explode(",", $guestsinks_raw); /* Deprecated $uservotes = explode(",", $uservotes_raw); $usersinks = explode(",", $usersinks_raw); */ $uservotes = 0; $usersinks = 0; $initial = 0; //Initial no. of votes [will be placed at -1 when all posts receive votes] 

(und so weiter…)

Ich habe von vielen Leuten gehört, dass es eine schlechte Übung ist, direkt in die MySQL-database zu gehen. Dass der Code in zukünftigen Versionen von WordPress aufbrechen kann.

Oder es ist in einigen Plugins wie “Gefällt mir” erforderlich?

Solutions Collecting From Web of "Ist es eine schlechte Übung, während der Entwicklung eines Plugins direkt zur MySQL-database zu gehen?"

Hallo @ JanoChen:

Die richtige Antwort lautet: “Es kommt darauf an.”

Im Allgemeinen ist es besser, integrierte WordPress-functionen als direkte SQL zu verwenden, wenn es eingebaute functionen gibt, die Ihnen das bieten, was Sie brauchen. Aber die Antworten auf viele der Fragen, die ich hier auf WPSE sehe, sind (leider) “Sie müssen direktes SQL dafür verwenden, weil WordPress einfach keine (n effiziente) function zur Verfügung stellt, die Sie benötigen.”

Im Fall des Vote It Up-Plugins ist es fraglich, ob die Wahl des direkten SQL korrekt war, da es keinen effizienten Ort gibt, um Stimmen in der WordPress-database zu speichern. Auf der anderen Seite gibt es diejenigen, die argumentieren, dass sie wp_postmeta und wp_usermeta verwendet wp_postmeta wp_usermeta , um diese Informationen zu speichern. Persönlich bin ich am Zaun für ein Wahlplugin; Ich müsste tatsächlich eine umsetzen (was ich getan habe, aber es war vor fast 2 Jahren und habe seitdem viel gelernt), um wirklich eine Meinung über den besten Weg zu haben, dies zu tun.

Eine Sache, die ich sagen werde, ist, dass ich, wenn immer möglich, lieber die integrierten Tabellen mit WordPress verwende, anstatt neue Tabellen hinzuzufügen. Das Hinzufügen einer Tabelle hat einen größeren Einfluss als das Hinzufügen von SQL-Code zum Zugriff auf die vorhandenen Tabellen. In Anbetracht dessen könnte ich vielleicht lernen, die Meta-Tabellen für ein Voting-Plugin zu verwenden, aber ehrlich gesagt kann ich das nicht eindeutig sagen, es sei denn, und bis ich tatsächlich versucht habe, eine solche functionalität zu implementieren.

AKTUALISIEREN

Ich lese gerade den Code von c.bavota und in gewisser Weise ist es gut, auf andere Weise beunruhigt es mich. Ich mag es, dass er Post-Meta verwendet, aber ich mag es nicht, dass er die Liste der durch Kommata getrennten user_ids in ein Post-Meta-Feld legt. Was passiert, wenn ein Beitrag 25.000 Stimmen erhält? Offensichtlich skaliert sein Code nicht für eine Website mit hohem Datenverkehr. Und sein Code würde es sehr langsam machen, eine Liste aller Beiträge zu erhalten, die von einem bestimmten Benutzer für eine Website mit einer großen Anzahl von Beiträgen gewählt wurden.

Wenn er alle Benutzer-IDs für Votes in ein Meta-Feld stopft, sollte er das besser skalieren, wie das Speichern von Post-IDs in Benutzermetas, da die Wahrscheinlichkeit, dass ein Benutzer 25.000 Mal oder gar 2500 Mal wählt, ziemlich klein ist. Oder er könnte Abstimmungen speichern, indem er die Benutzer-ID in den post- "user_vote_{$user_id}" , dh "user_vote_{$user_id}" (obwohl vielleicht 25.000 "user_vote_{$user_id}" eigene Probleme verursachen würden).

OTOH, wenn Sie wirklich Stimmen von Benutzern verfolgen müssen, könnte ich für eine Tabelle argumentieren, und direktes SQL könnte Sinn machen.

Darüber hinaus stellt er seinen eigenen Webdienst bereit, anstatt die integrierte AJAX-functionalität für Webdienste zu verwenden. Obwohl es mir nicht gefällt, dass die integrierte functionalität nicht REST-konform ist, denke ich nicht, dass es eine gute Idee ist, eine Web-Service-Infrastruktur neu zu erstellen, wenn Sie es nicht richtig machen. Es richtig zu machen wäre integrierte Sicherheit und c.bavota Code sorgt sich nicht um Sicherheit; Kein Entweichen von $_POST Werten, keine Verwendung von Nonces, nichts.

Und sein Code könnte leicht Stimmen zählen, wenn zwei oder mehr Leute gleichzeitig wählen. Was ein bisschen gruselig ist, ist, dass dieser Typ Premium-Themen verkauft und seine How-To-Artikel Code haben, der gegen mehrere bekannte Best Practices verstößt. Aber ich denke, dass er als Themenanbieter, der Code mit Sicherheits- oder Skalierbarkeitsproblemen hat, kaum einzigartig ist. .

Ich habe einen Kommentar zu diesen Themen hinterlassen und vorgeschlagen, seine Benutzer sofort zu warnen und mit besseren Techniken zu aktualisieren, aber sie ist derzeit in Maßen. Hoffen wir, dass er es veröffentlicht.

UPDATE2

Warum sollten Sie functionen wie update_post_meta() anstatt die database direkt zu aktualisieren? Mehrere Gründe, aber viel wichtiger für Plug-ins oder Themen, die Sie verteilen möchten, als für Code, den Sie für Ihre eigene Website schreiben (obwohl es im Idealfall auch für Letzteres hilfreich ist):

  1. Durch eine kleine Chance kann WordPress die databasestruktur für Meta verändern. Sie haben es schon einmal getan und könnten es wieder tun. Wenn Sie die integrierten functionen anstelle von SQL verwenden, wird Ihr Code weiterhin funktionieren, aber offensichtlich wird direkter SQL-Code bei einem WordPress-Upgrade beschädigt.

  2. Wenn Sie update_post_meta() , funktioniert es für Single Site und Multisite. Der direkte SQL-Code funktioniert nur für den einen, aber nicht für den anderen.

  3. Wenn Sie update_post_meta() und jemand ein Plugin verwenden möchte, das häufig aufgerufene Werte in MemCached speichert, wird Ihr Code dies unterstützen, aber nicht, wenn Sie direktes SQL schreiben.

  4. Im Allgemeinen, wenn ein Plugin oder Theme hakt update_post_meta() der Hook funktionieren, wenn Sie update_post_meta() aber nicht, wenn Sie direktes SQL verwenden.

  5. Und ich bin mir sicher, dass es andere Gründe gibt, an die ich momentan nicht denken kann.

Es genügt zu sagen, dass die Verwendung der integrierten functionen Robustheit und Flexibilität bietet, die direkte SQL nicht erreichen kann; Verwenden Sie also nur Direct SQL, wenn Sie dies nicht mit integrierten functionen tun können. JMTCW.

Für die meisten Plugins genügt es, die WordPress Options-API zu verwenden . Während dies für Buttons, Strings und andere einfache Dinge gut funktioniert, benötigen komplexere Plugins manchmal ihre eigene databasetabelle. Wenn Sie sich in einer solchen Situation befinden, sollten Sie die offiziellen Richtlinien auf der Seite Erstellen von Tabellen mit Plugins befolgen.

Es ist nichts falsch daran, direkt in die database zu gehen, solange Sie die Eingabe richtig verifizieren und sicherstellen, dass Ihr Code absolut sicher ist. WordPress hat viele functionen, die das sehr viel einfacher machen (siehe auch: Erstellen von Tabellen mit Plugins ), weshalb ich das persönlich empfehle.