5 choses que vous ne saviez pas que vous pourriez faire avec le fichier de configuration WordPress

Publicité

Au cœur de chaque installation WordPress se trouve le wp-config.php fichier, un fichier si sacré et enveloppé de mystère que chaque utilisateur de WordPress sait qu'il devrait ne jamais être touché.

Ou devrait-il?

En fait, il y a beaucoup de hacks utiles moins connus qui peuvent être sans endommager WordPress de quelque manière que ce soit, et il est temps que vous augmentiez vos compétences WordPress d'un cran. Lisez la suite pour 5 de mes astuces wp-config préférées.

Cet article est strictement destiné aux sites WordPress.org auto-hébergés, pas à ceux hébergés sur WordPress.com (quelle est la différence? Quelle est la différence entre gérer votre blog sur Wordpress.com et Wordpress.org?Wordpress alimentant désormais 1 site Web sur 6, ils doivent faire quelque chose de bien. Pour les développeurs expérimentés et le novice complet, Wordpress a quelque chose à vous offrir. Mais juste au début ... Lire la suite ).

Avant de commencer, sachez que vous pouvez potentiellement empêcher WordPress de se charger si vous gâchez la syntaxe de ce fichier, même avec quelque chose d'aussi stupide que d'oublier un point-virgule. Cependant, il est également incroyablement facile de le dupliquer avant de commencer la modification afin d'avoir une sauvegarde. Si vous cassez quelque chose, supprimez simplement votre fichier modifié et renommez la sauvegarde - tout ira bien à nouveau avec le monde. Il est en fait très difficile d'endommager définitivement une installation WordPress, à moins de supprimer l'intégralité de votre base de données. Avant d'essayer l'une de ces options, vous pouvez également consulter notre

guide ultime pour corriger 500 erreurs de serveur interne Le guide ultime pour résoudre 500 erreurs de serveur interne et pages blanches vierges dans WordPressVous rencontrez des problèmes avec 500 erreurs de serveur interne et des pages blanches dans WordPress? Voici comment les corriger immédiatement. Lire la suite .

Le fichier wp-config.php se trouve à la racine de votre installation WordPress et vous oblige à vous connecter via FTP ou SFTP pour le modifier. Si vous ne savez pas comment procéder, le contenu de cet article peut ne pas être adapté à votre niveau de compétence, mais voici quelques recettes IFTTT utiles à utiliser avec WordPress 5 recettes IFTTT étonnantes pour les utilisateurs de WordPressIFTTT est l'outil d'automatisation de l'utilisateur puissant de choix; et WordPress est le couteau suisse ultime du blogueur. Imaginez le genre de domination mondiale que vous pourriez réaliser en combinant les deux! Lire la suite (qui n'implique pas la modification de fichiers).

Consigner les erreurs dans un fichier

Parfois, la sortie d'un tas d'erreurs désagréables sur le front-end public de votre site n'est vraiment pas souhaitable. Enregistrez les erreurs dans un fichier à la place! Définissez les éléments suivants, puis attendez un moment et vous verrez un nouveau error.log dans le wp-content / répertoire se remplissant lentement. C’est une bonne idée de le désactiver dès que vous avez un échantillon suffisamment bon des erreurs, car il n'y a pas de rotation ou de limite de journal intégrée - vous pouvez remplir votre serveur entier avec des gigaoctets de journaux!

define ('WP_DEBUG', true); // revenir à false pour désactiver. if (WP_DEBUG) {define ('WP_DEBUG_LOG', true); define ('WP_DEBUG_DISPLAY', false); @ini_set ('display_errors', 0); }

Recherchez les lignes avec PHP_ERROR plutôt que REMARQUER ou ATTENTION - le dernier ne cassera pas votre site, mais le premier le pourrait.

Désactiver les révisions de poste

J'ai trouvé une fois un article avec plus de 100 révisions: c'est 100 lignes supplémentaires dans le tableau des messages qui ne sont pas nécessaires. Désactivez entièrement les révisions de poste avec la ligne simple suivante:

define ('WP_POST_REVISIONS', false);

ou

define ('WP_POST_REVISIONS', 3);

pour les limiter à un nombre sensible à la place. Bien sûr, certaines personnes aiment avoir des révisions de poste, en particulier dans un environnement où les éditeurs apportent des modifications à votre travailler - mais si c'est juste vous qui écrivez, et que vous avez tendance à travailler sur des articles un peu à la fois, ça ne vaut pas la peine il. Notez que cette astuce ne supprimera aucune révision de publication existante, elle empêchera simplement la création de nouvelles.

Table d'utilisateurs partagés

Parfois, tu veux plus d'un Installation de WordPress - nous le faisons ici sur MakeUseOf.com. Mais donner aux utilisateurs une connexion distincte pour chaque site est tout simplement ridicule, et gérer un réseau de blogs "multisite" n'aide pas non plus (croyez-moi, nous avons essayé) - en fait, cela complique trop la situation quand quelques lignes dans votre wp-config.php sont vraiment tout ce dont vous avez besoin. Ce que vous voulez, c'est ce qu'on appelle une table d'utilisateurs partagée - c'est-à-dire que, tandis que chaque blog reste sa propre entité avec des plugins et des publications séparés, etc., seule la base de données des utilisateurs est partagée.

Tout d'abord, décidez de votre blog principal - ce sera là que la gestion des utilisateurs se fera. Appelons ça le blog A. Les blogs B et C seront des «sous-blogs» et s'inspireront de la table des utilisateurs du blog principal A, et je suppose qu'ils seront installés dans des dossiers distincts. Dans les fichiers wp-config pour B et C, ajoutez les lignes suivantes. Dans cet exemple, le blog principal utilise un préfixe de base de données «blogA».

define ('CUSTOM_USER_TABLE', 'blogA_users'); define ('CUSTOM_USER_META_TABLE', 'blogA_usermeta'); 

Le préfixe de la base de données est un terme spécifique choisi lors de la configuration de votre premier blog (celui utilisé pour tout gérer). La valeur par défaut est wp_ mais les nouvelles installations vous encourageront à changer cela. Si vous n'êtes pas sûr, c'est le mot qui vient au début de tous les noms de table de votre base de données.

Vous devez également vous assurer que les domaines de cookies sont les mêmes - sans cette étape, les utilisateurs devront se connecter séparément à chaque site (bien qu'avec le même mot de passe et les mêmes capacités, qui sont maintenant partagés).

define ('ADMIN_COOKIE_PATH', '/'); define ('COOKIEPATH', '/'); define ('SITECOOKIEPATH', '/'); define ('COOKIEHASH', md5 ('CHANGETHIS')); 

Assurez-vous de remplacer CHANGETHIS par votre propre chaîne de caractères générée aléatoirement pour sécuriser vos cookies. Enfin, vous devriez voir un certain nombre de lignes similaires à la capture d'écran ci-dessous, définies avec des valeurs aléatoires de «sel» et de «clé». Assurez-vous que c'est la même chose dans chaque fichier de configuration; si vous n'en avez pas déjà, utilisez cette page pour les générer.

Heureusement, aucune des modifications que vous apportez à wp-config.php ne sera perdue avec chaque mise à niveau, mais il y a une autre petite modification que vous devrez peut-être refaire si la mise à niveau la remplace: dans wp-includes / capabilities.php.

le _init_caps () c'est là que les capacités de l'utilisateur actuel sont récupérées - si nous ne changeons pas cela, l'utilisateur pourra se connecter, mais ne fera rien. Trouvez le code suivant:

function _init_caps ($ cap_key = '') {global $ wpdb; if (vide ($ cap_key)) $ this-> cap_key = $ wpdb-> get_blog_prefix (). «capacités»; sinon $ this-> cap_key = $ cap_key; $ this-> caps = get_user_meta ($ this-> ID, $ this-> cap_key, true); si (! is_array ($ this-> caps)) $ this-> caps = array (); $ this-> get_role_caps (); }

et changer le

$ this-> cap_key = $ wpdb-> get_blog_prefix (). «capacités»;

il est donc codé en dur quel que soit le préfixe de votre blog principal

$ this-> cap_key = 'blogA_capabilities';

Chaque mise à niveau, vérifiez simplement que vous avez toujours un accès complet à chaque blog; sinon, refaites ce correctif.

Correction de l'URL du site

Si vous avez foiré les paramètres d'URL, vous pouvez parfois vous verrouiller hors de la zone d'administration dans un scénario de poulet et d'œufs désagréables. Vous pouvez y remédier en accédant aux paramètres, mais vous ne pouvez pas accéder aux paramètres car les paramètres sont incorrects; (

Heureusement, vous pouvez remplacer toutes les options de base de données où l'URL est stockée - jet ajoutez les lignes suivantes à votre fichier de configuration:

define ('WP_SITEURL', ' http://example.com/' );

define ('WP_HOME', ' http://example.com/' );

Ne cassez pas l'URL lors de la migration

Migration d'un site WordPress vers un nouveau domaine 3 plugins pour migrer facilement un site WordPress, testé et testéCes plugins Wordpress peuvent semi-automatiser l'ensemble du processus de migration d'un site WordPress pour vous. Lire la suite peut être fait de plusieurs manières, mais si vous avez opté pour la base de données de ligne de commande et le vidage de fichiers, c'est le moyen le plus courant pour le site de devenir inaccessible. Plutôt que de le réparer après coup, ajoutez la ligne suivante pour mettre WordPress en mode relocalisation.

define ('RELOCATE', true);

Maintenant, une fois que vous avez tout migré, visitez /login.php et les paramètres d'URL seront mis à jour pour vous. Vérifiez que cela a fonctionné, puis supprimez cette ligne de la configuration.

La maîtrise de votre wp-config.php est une étape sur la voie de la maîtrise de WordPress - je vous recommande également d'apprendre à interagir directement avec la base de données avec ces requêtes SQL pratiques 7 requêtes de base de données Wordpress pour rechercher n'importe quoi sur votre blogL'exécution d'un blog Wordpress ou d'un site Web n'est pas vraiment un gros problème au début. C'est en fait assez simple. Vous installez Wordpress sur un serveur web, vous téléchargez et installez un thème, démarrez ... Lire la suite .

Vous avez d'autres hacks wp-config que vous aimeriez partager?