Sur la page d'accueil, j'ai quelques liens:
<a class="link" data-id="1">first link</a>
<a class="link" data-id="2">second link</a>
<a class="link" data-id="3">third link</a>
Lorsque l'un de ces liens est cliqué, je souhaite envoyer une demande ajax à un fichier php afin de mettre à jour la base de données pour augmenter le nombre de vues de cette publication.
$(document).ready(function(){
$(document).on('click', '.link', function(e){
var post_id = $(this).data('id');
$.ajax({
url: "views.php",
type: 'POST',
data: {id: post_id},
success: function(){
alert("done");
}}); // ajax
}); // on click
}); // ready
Dans views.php:
//Check if the id is posted.
if( isset($_POST['id']) ){
//Assigning the id to a variable.
$id = $_POST['id'];
//Check if the id is an integer.
$pattern = '/[0-9]/';
if( preg_match($pattern, $id) ){
//Check that the user didn't visit that post before.
$post_cookie = 'p_' . $id;
if( !isset($_COOKIE[$post_cookie]) ){
//Insert or update if the post id exists.
$query = $conn->prepare('INSERT INTO posts (id, views) VALUES (:id, 1) ON DUPLICATE KEY UPDATE views = views+1');
$query->bindValue(':id', $id, PDO::PARAM_INT);
$query->execute();
//Set a cookie with the post id to indicate that the post is viewed.
setcookie( $post_cookie, '1');
}// No cookie with that name (the user didn't visit that post).
} // id matches the pattern.
} // id is posted.
Je pourrais utiliser d'autres options que l'ID de publication pour ajouter/mettre à jour les vues, mais je me demande si cette méthode est sans danger ou si je devrais utiliser admin-ajax.php.
OMG ... Non, non, non !!! Ne fais jamais ça comme ça ...
Pourquoi? Il y a plusieurs raisons...
Vous ne pourrez rien faire avec les utilisateurs dans votre views.php
- et si vous deviez compter uniquement les vues des utilisateurs anonymes (non connectés)?
Que se passe-t-il si table_prefix
est réglé sur ''? Votre table posts
provoquera des conflits ...
Que se passe-t-il si certains plug-ins fonctionnent sur une connexion DB? Votre script se connectera à la mauvaise base de données ou provoquera d’autres conflits.
Et si, pour des raisons de sécurité, votre script ne serait pas exécutable?
Il y a beaucoup d'autres raisons pour lesquelles vous ne devriez pas le faire de cette façon ...
Il y a une raison pour avoir les meilleures pratiques et normes. Et la vie de tous les développeurs est bien plus simple et agréable si tout le monde code selon ces normes et pratiques ... De cette manière, il est facile de déboguer tous les appels AJAX, etc.
Donc oui, vous devriez absolument utiliser admin-ajax.php
et wp_localize_script
, et $wpdb
, et l'échappement SQL approprié, et ainsi de suite ...
Oui, ce sera visible. Mais ... Ce ne sera pas un appel standard AJAX - il sera donc plus difficile à comprendre ...
Faisons quelques expériences rapides ... Jetons un coup d'oeil à ces deux codes:
1.
add_action( 'wp_ajax_get_post_status', 'ajax_get_post_status_callback' );
function ajax_get_post_status_callback() {
$id = $_POST['id'];
$post = get_post( $id );
if ( $post ) {
echo $post->post_status;
die;
}
echo 0;
die;
}
2.
include "ustawienia-polaczenia.php";
$i = $_POST['id'];
$wiersz = PostsQuery()::create()->filterById( array($i) )->find();
if ( $wiersz ) {
echo $wiersz->post_status;
die;
}
echo 0;
die;
Lequel est le plus facile à lire? Je parie le premier. Pourquoi? Parce qu'il utilise WP fonctions essentielles et que tout le monde sait comment elles fonctionnent. Je sais (ou je peux facilement vérifier) quelle est la fonction get_post
et ainsi de suite. Ce code respecte également tous les filtres et toutes les actions - il ne générera donc aucun conflit avec les autres plugins ...
D'autre part, le second code est juste un gâchis ... Il inclut un autre fichier, il utilise une connexion DB étrange (oui, c'est Propel). Il est même difficile de deviner s'il s'agit du même DB ou d'un autre et comment cela fonctionne. Et il ignore complètement les autres plugins ...
Donc oui - tout le monde verra que votre code envoie des fichiers étranges AJAX et le fichier responsable de son traitement. Le problème est que le débogage de votre code étrange/personnalisé demandera beaucoup plus de temps ... Et il est beaucoup plus probable que votre code crée des problèmes et des conflits ...