Quiz 2 — Architecture & hooks

Une action (do_action) = « il s’est passé quelque chose », ton callback agit (echo, enregistre). Un filtre (apply_filters) = une valeur passe par ta fonction qui la modifie et la retourne.

La priorité (défaut 10, plus petit = plus tôt) et le nombre d’arguments acceptés (accepted_args). Oublier ce dernier = « argument manquant ».

Le contenu disparaît (la fonction retourne null). Un filtre doit toujours retourner la valeur (modifiée ou non). Bug classique.

On enregistre CPT, taxonomies, shortcodes… init se déclenche après le chargement de WordPress, avant tout rendu. register_post_type doit y être appelé.

L’enqueue (wp_enqueue_style/script) sur le hook wp_enqueue_scripts — jamais de <link>/<script> en dur. WordPress gère dépendances, versions, ordre.

La boucle qui parcourt les résultats de la requête principale (have_posts() / the_post()) et affiche chaque contenu. Le bloc Query Loop en est la version no-code.

À modifier la requête principale avant exécution (ex. articles par page sur les archives). Toujours vérifier ! is_admin() et is_main_query() pour ne pas tout casser.

L’ordre selon lequel WordPress choisit le fichier de gabarit du plus spécifique au plus général (single-livre.php > single.php > index.php). Le routing par convention.

Avec $wpdb->prepare("… WHERE id = %d", $id) (placeholders %d/%s/%f). Jamais de concaténation. Et privilégier WP_Query/get_posts au SQL brut.

Options (get_option) = config persistante. Transients (set_transient) = cache avec expiration. Le cache objet accélère les requêtes répétées. À invalider au bon moment.

Le planificateur de tâches de WordPress, déclenché par le trafic (pas un vrai cron système). Il publie les articles planifiés et lance les tâches récurrentes (wp_schedule_event).

Parce qu’un nouveau CPT crée des URLs (/livres/…) qui n’existent qu’après un flush des règles de réécriture. On l’appelle une fois à l’activation (sinon 404).

wp-config.php = identifiants BDD, clés (salts), constantes (le .env de WordPress). WP_DEBUG = true affiche les erreurs PHP (avec WP_DEBUG_LOG → debug.log). Jamais affiché en prod.

À administrer WordPress en ligne de commande (wp plugin, wp post, wp search-replace, wp db export). Indispensable en pro, surtout search-replace (gère les données sérialisées).

Dans wp-content/ (themes/, plugins/, uploads/, mu-plugins/). On ne touche jamais wp-admin/ ni wp-includes/ (écrasés aux mises à jour).

Via $wpdb->prefix (jamais wp_ en dur), car le préfixe est configurable. Ex. "{$wpdb->prefix}mytable".

À agir selon le contexte (« où/qui sommes-nous »). ⚠️ La plupart ne sont fiables qu’après le hook wp (pas trop tôt).

En déclarant tes hooks : do_action('mon_hook', $data) et apply_filters('mon_filtre', $valeur). D’autres pourront s’y brancher sans modifier ton plugin.

Parce que save_post tire aussi pour les révisions/autosaves → double déclenchement. On teste wp_is_post_revision($post_id) et on sort. Puis vérif nonce + capability.

À vérifier la capability de l’utilisateur côté serveur avant une action sensible. Cacher un bouton ne protège rien : il faut vérifier au traitement.