Wordpress ne respecte pas la hiérarchie des modèles (récupère index.php au lieu de single.php ou page.php)
J'ai rencontré une erreur étrange lors du développement d'un thème personnalisé.
Après avoir fini de modifier le modèle pour une vue unique de type publication personnalisée, je suis passé au travail sur les fichiers de modèle pour les pages et j’ai réalisé que Wordpress pointait en fait sur le fichier modèle index.php plutôt que sur page.php dans mon thème pour générer l’apparence de la page. .
J'ai essayé de modifier les paramètres de la page d'accueil du site Web et de la page d'accueil du blog dans les paramètres de "lecture". J'ai essayé d'actualiser la structure de permaliens (normalement j'utilise% postname%). J'ai également essayé de revenir à la structure standard /? = Post_id. Dans ce cas, ça marche bien ... mais rien avec% postname% ne fonctionnera pas.
J'ai désactivé les plugins, mais rien ne change. Il refuse simplement de travailler avec de jolis permaliens. En fait, les permaliens fonctionnent correctement pour mon type de publication personnalisé et ne génèrent pas d'erreurs 404. Mais pour chaque page et chaque message, on essaiera d'extraire index.php plutôt que single.php et page.php (ou les modèles suivants pour les pages). J'ai vérifié la configuration de mon type d'article personnalisé ... mais il n'y a pas de conflit possible avec les pages (la réécriture d'URL est totalement différente de toute chaîne wordpress standard).
J'ai vérifié mon fichier .htaccess, ce qui est assez standard, comme dans la plupart de mes installations:
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
METTRE À JOUR
J'ai décidé de tout jeter, en tant que site de développement de tests, et j'ai tout recommencé pour une nouvelle installation. Dumpé la base de données entière, a supprimé les fichiers d'installation. Installation propre et activé wp_debug = true. Au début, j'ai remarqué une erreur dans le tableau de bord:
ERROR: The themes directory is either empty or doesn’t exist. Please check your installation.
Je pense que c'est parce que j'ai renommé le dossier wp-content en "content"
Je l'ai déjà fait sur d'autres installations avec ce code (bien entendu, "mon domaine" est mon domaine réel dans mon wpconfig ...)
define('WP_CONTENT_FOLDERNAME', 'content' );
define('WP_CONTENT_DIR', ABSPATH . WP_CONTENT_FOLDERNAME );
define('WP_CONTENT_URL', 'http://mydomain.com/' . WP_CONTENT_FOLDERNAME );
define('WP_PLUGIN_DIR', WP_CONTENT_DIR . '/plugins' );
define('WP_PLUGIN_URL', WP_CONTENT_URL . '/plugins' );
Après vérification et rechargement de la page, la chaîne d'erreur a disparu. J'ai pu installer le thème correctement (donc Wordpress devait connaître son dossier d'emplacement ...)
Cependant, le problème des permaliens d'URL persiste (veut extraire index.php au lieu du modèle page.php pour les pages ou single.php pour les publications). Cela me rend fou parce que c'est une nouvelle installation propre.
MISE À JOUR 2
maintenant, je teste avec TwentyEleven/Ten et jette toujours la même erreur ... donc je dois exclure les plugins et mon thème personnalisé ... cela a probablement à voir avec ma configuration de serveur, htaccess ou wpconfig probablement ... mais je vraiment se demander ... parce que cela fonctionne sur le même serveur où j'ai une demi-douzaine de sites wordpress configurés de manière similaire
MISE À JOUR 3
après avoir modifié et mis à jour le fichier wp-config.php plusieurs fois, je l'ai parfois fait fonctionner ... mais pour une raison quelconque, il ne cesse de s'effondrer ... les articles et pages d'un blog sont redirigés vers index.php (blog home) ou page modèle contenant le blog à la maison (si défini dans les paramètres "lecture" de wordpress admin). Les types de messages personnalisés, les archives et les pages de forum bbpress (publications individuelles et archives), les taxonomies ... tout fonctionne correctement. Ce ne sont que des pages et des posts. J'ai vérifié deux fois la configuration php et les variables du serveur, tout semble normal
Je vais répondre à ma propre question dans l’intérêt des gens qui courraient le même problème que moi.
dans ma configuration, j'avais un plugin gérant les taxonomies; l'un d'entre eux avait le slug de réécriture réglé sur "année" - eh bien, il s'avère que cela est probablement en conflit avec les archives basées sur les dates (?) et que mes publications et pages ne se chargent pas, mais plutôt redirigent l'utilisateur vers le blog personnel - de toute évidence, il y en avait Problème dans la hiérarchie des modèles Wordpress; Je n'ai pas enquêté plus loin
Je n'ai pas détecté l'erreur rapidement, car je ne vidais pas correctement les permaliens lors de la désactivation des plugins. L'erreur apparaissait également de manière aléatoire (parfois, mes permaliens DID fonctionnaient bien que la réécriture de la taxonomie était toujours définie).
J'ai fini par renommer le slug en "point", puis en supprimant le fichier .htaccess, en le recréant et en créant/vidant des permaliens depuis la page permaliens de Wordpress.
qui semble l'avoir résolu une fois pour toutes
alors ... si vous vous trouvez dans une situation similaire, vérifiez toutes les modifications qui modifient la structure du permalien, même les types de publications et les taxonomies personnalisés, pensez au slug que vous utilisez et s'il peut entrer en conflit avec quelque chose sinon même pas évident
à votre santé
J'ai fait face au même problème et je viens de résoudre le problème après avoir passé près d'une heure à le résoudre.
Ainsi, si votre page CPT (type de message personnalisé) utilise le index.php et non le modèle single-post_type, assurez-vous de ne pas utiliser query_posts de manière incorrecte. Pour moi, il s’est avéré que j’ai oublié d’appeler wp_reset_query sur l’une des pages de la barre latérale après avoir utilisé query_posts.
Il suffit de parcourir toutes vos pages et Ctrl+F pour query_posts et vérifiez manuellement que chacun des appels query_posts est fermé par un appel wp_reset_query après celui-ci.
Tout d’abord, activez WP_DEBUG dans wp-config.php.
Peut-être que vous changez la requête par défaut. Utilisez-vous query_posts quelque part? Jetez un coup d'œil à l'objet global $wp_query. Si c'est le cas, vous pouvez essayer d'essayer WP_Query class ou d'exécuter wp_reset_query() à la place.
Je pense que vos réglages dans WP-config peuvent toujours être incorrects - il se peut que votre ABSPATH renvoie la mauvaise valeur.
Les lignes que vous devez vérifier et modifier sont --- (j'ai pris ceci de Mark Jaquith skeleton local installer WordPress)
// Custom Content Directory
define( 'WP_CONTENT_DIR', dirname( __FILE__ ) . '/content' );
define( 'WP_CONTENT_URL', 'http://' . $_SERVER['HTTP_Host'] . '/content' );
J'avais une page parent avec slug "valentines-day" et c'était suffisant pour forcer ma page à utiliser single.php (modèle de post) de manière inappropriée! Problème très similaire à vous en utilisant "année" dans la limace. Tous les mots de type date tels que "jour" et "année" dans le slug interfèrent clairement avec la sélection automatique du modèle.
Cette fonction peut être utilisée pour forcer n’importe quel page/URL à utiliser n’importe quel modèle - ce qui est très utile pour corriger les cas étranges comme celui-ci. https://codex.wordpress.org/Plugin_API/Filter_Reference/template_include