Modification des fichiers principaux de WordPress

Pourquoi?

Parfois, une solution simple pour modifier le comportement de WordPress lui-même ou d'un plugin pourrait être de modifier directement les fichiers du plugin ou de WordPress. En venant avec une telle idée, la réponse habituelle est:

Ne piratez pas le cœur.

Pourquoi est-ce généralement une mauvaise idée de changer les fichiers principaux?

Considérer?

Parfois, cependant, des choses qui peuvent être critiques pour un site sont tout simplement impossibles à faire, d'une manière agréable sans modifier les fichiers de base. Dans une telle situation, que devez-vous savoir avant de commencer et de commencer le piratage de base?

Comment?

Vous avez considéré toutes les options, mais la seule solution consiste à pirater les fichiers principaux. Comment devez-vous procéder? Comment le fait d'avoir un noyau modifié influencera-t-il les flux de travail, comme la mise à jour?

core

— googletorp
source

Je suis fortement en désaccord avec toute recommandation de pirater le cœur car je n'ai pas encore trouvé une seule chose que je ne pouvais pas contourner. Les seules personnes qui ont un noyau de piratage d'entreprise pour un site de production sont celles qui n'ont absolument pas besoin de lire quoi que ce soit sur ce sujet car elles font probablement déjà partie de l'équipe principale de WordPress. Expliquer aux gens comment le faire donne simplement à 99 personnes sur 100 qui ne devraient certainement pas le faire une manière de rationaliser leurs décisions. Et je détesterais vraiment voir cela activé ici. JMTCW.

— MikeSchinkel

En guise de suivi, voici un exemple d'une question qui a été les premières réponses "Ce n'est pas possible" et j'ai répondu avec un exemple montrant comment: wordpress.stackexchange.com/questions/972/#984 Il y a (presque toujours) un moyen de faites-le sans noyau de piratage.

— MikeSchinkel

Si vous modifiez le noyau, vous devrez refaire les modifications après chaque mise à niveau et vous rendrez votre installation non standard, il est donc plus difficile pour les gens de vous aider. Il suffit de créer un plugin, un widget, un modèle, un crochet ou l'une des nombreuses méthodes que wordpress vous offre pour ne pas avoir à changer le noyau.

— Wadih M.

Wadih a raison. J'ai apporté des modifications à certains des fichiers de base pour corriger / améliorer / personnaliser diverses choses et j'ai toujours été frustré lors de la mise à niveau car je dois vérifier les modifications et appliquer mes correctifs aux nouveaux fichiers. Cela est encore plus frustrant lorsque les nouveaux fichiers sont trop différents des anciens et que les emplacements des modifications ne sont plus évidents (ni même présents du tout).

— Synetech

C'est comme je le craignais; Parfois, lorsqu'il n'y a pas de hooks raffinés (comme la modification de Mes sites), les seuls hooks qui fonctionnent pour l'astuce de sortie en mémoire tampon sont admin_body_classet admin_footerce qui signifie capturer la page entière . Je viens de l'essayer et il y a> 2 Mo de contenu qui doit être recherché pour la section pertinente, puis analysé et modifié avant la sortie. Ou, je peux ajouter une ligne de code dans la partie droite de my-sites.phpet utiliser un outil de comparaison pour appliquer le correctif après les mises à jour (en supposant qu'il ait été modifié du tout). Il est vraiment difficile de plaider contre la modification du noyau dans des scénarios comme celui-ci.

— Synetech

Réponses:

Si vous devez pirater le noyau, envisagez de le faire de manière à le rendre extensible pour les autres.

Ajouter un crochet d'action

Neuf fois sur dix, vous pourriez faire ce que vous vouliez si seulement il y avait un do_actionappel supplémentaire dans un fichier spécifique. Dans ce cas, ajoutez l'action, documentez-la et soumettez un correctif via Trac . S'il y a une bonne raison à votre patch (c'est-à-dire que vous n'êtes pas le seul à l'utiliser), vous pouvez probablement l'ajouter au core.

Ensuite, créez un plug-in personnalisé (vous n'avez pas besoin de le libérer / le distribuer!) Qui se connecte à ce nouveau hook et remplit toutes les fonctions que vous en avez besoin.

Refactoriser un fichier core

D'autres fois, vous pourriez avoir besoin d'un morceau de code pour se comporter différemment. Passez une variable par référence, par exemple, ou renvoyez une valeur plutôt que de l'écho. Prenez le temps de vous asseoir et de remanier le code pour qu'il fasse ce que vous en avez besoin ... puis envoyez un patch via Trac pour que le reste d'entre nous puisse bénéficier de votre travail.

Voyez-vous un thème se développer ici? Le piratage de base n'est pas nécessairement un non-non ... juste quelque chose que la plupart des développeurs décourageront fortement pour les nouveaux utilisateurs ou les programmeurs novices (si vous nous demandez comment faire quelque chose, nous vous proposerons un plug-in à chaque fois avant même envisager de vous suggérer de pirater le noyau).

Le noyau de piratage est la façon dont WordPress se développe et évolue, mais c'est dangereux pour quelqu'un qui apprend juste PHP ou n'a aucune expérience de travail avec les fichiers WP. Veuillez commencer par un plug-in avant de toucher au core - si vous cassez un plug-in, vous pouvez le désinstaller rapidement (en le supprimant via FTP si nécessaire) ... mais si vous cassez le core, de mauvaises choses peuvent arriver à votre site et potentiellement à votre base de données ainsi.

Mais si vous êtes dans une situation où un hack de base est inévitable, faites le changement. Aussi, publiez votre modification dans un endroit bien en vue (si votre blog est très visible, cela pourrait être suffisant ... mais je suggère Trac parce que c'est ainsi que les changements de communauté sont intégrés dans la prochaine version). Votre changement pourrait être la solution miracle qui pourrait résoudre des problèmes dans une centaine de sites différents ... contribuez donc à la communauté qui vous a aidé à créer votre site.

Si le changement est engagé, votre hack devient partie intégrante du noyau et vous n'aurez plus à vous en soucier à l'avenir. Si ce n'est pas le cas, vous avez au moins une documentation détaillée sur la façon de réimplémenter le hack après avoir mis à niveau WP en 3 mois.

— EAMann
source

Beaucoup mieux que la mienne :)

— hakre

Ne piratez pas le cœur.

Eh bien, c'est parce que c'est une suggestion pour le premier niveau, les utilisateurs inexpérimentés. Ceux qui pirateraient le cœur briseraient leur installation, ils ne peuvent pas garantir que leurs modifications persistent une mise à jour, etc.

Bien sûr, hack core!

Bien sûr, vous pouvez réellement pirater le cœur, par exemple en utilisant un système de gestion de version comme SVN. Il vous aide à garder vos propres modifications sur le code principal en ligne avec les mises à jour du projet. Il aide également à créer des correctifs pour Wordpress et à les envoyer au projet.

Le noyau de piratage est en fait faire évoluer Wordpress.

Considérations

Si vous ne voulez pas installer un SVN complet et que vous savez toujours quels (certains) fichiers vous avez modifiés, vous pouvez utiliser plus d'outils de bas niveau comme Diff / Merge (pour win: WinMerge ) ou des éditeurs avec des capacités de comparaison (par exemple Notepad ++ avec Compare Plugin ). Sous Linux, vous pouvez facilement installer des utilitaires de ligne de commande qui font de même. L' éditeur Geany est livré avec une belle intégration shell. .

Je préfère Eclipse PDT pour les travaux difficiles. Mais ce n'est pas pour la modification rapide ou le piratage.

Je dirais donc que si vous utilisez les bons outils et que vous voulez faire attention à pirater le cœur, c'est la voie à suivre. Si vous piratez quelque chose ensemble qui reste sur un autre serveur d'utilisateurs Noob (ouais, Wordpress est assez populaire), fournissez simplement un plugin qui peut être lancé facilement s'il casse quelque chose.

— hakre
source

Le hacking core n'est JAMAIS une bonne solution à long terme. JAMAIS.

— Fredy31

@ Fredy31; C'est le seul moyen de maintenir votre installation wordpress à jour, fonctionnelle et sécurisée. De plus, le "long terme" dont vous parlez ici est vraiment long s'il faut deux ans et plus entre la fourniture d'un correctif à Wordpress et son obtention. Encore plus longtemps pour signaler un problème sans correctif. Prends soin de toi.

— hakre

Évidemment, le piratage du noyau est gênant, mais je trouve la résistance et le vitriol ici surprenant. Dans à peu près tous les autres domaines des logiciels libres, la fourche est activement encouragée. Pourquoi la personnalisation de WordPress est-elle si anathème? J'ai vu d'innombrables autres projets faire exactement ce que hakre a suggéré en utilisant un RCS pour créer une version modifiée d'un programme tout en restant à jour avec le tronc. +1 pour donner l'avertissement évident mais dire la vérité que c'est effectivement possible et donner la suggestion évidente de la façon dont cela peut être fait avec le moins de difficulté.

— Synetech

Oh, et je viens de me rappeler que les thèmes enfants font exactement cela! Lorsque vous créez un thème enfant, vous bifurquez essentiellement le parent et chaque fois que le parent est mis à jour, vous devez copier manuellement toutes les modifications apportées à l'enfant. Donc, cette haine de modifier le noyau est incompatible avec un autre comportement WordPress identique qui a accepté.

— Synetech

Les problèmes sont les suivants:

Chaque fois que vous effectuez une mise à jour du noyau (par exemple à cause d'un correctif de sécurité, etc.), vous devrez le mettre à jour manuellement, au lieu d'exécuter le programme de mise à jour automatique.
Si vous le souhaitez, rendez-vous la vie plus facile:
- marquer chaque changement avec un marqueur commun (.eg // PATCH STARTet // PATCH END)
- utilisez un outil comme WinMerge pour comparer la source existante avec la nouvelle source et copiez les modifications si nécessaire.
- vous devrez faire attention au cas où la zone de code sur laquelle vous copiez a changé et apporter les modifications appropriées à vos correctifs
- sachez qu'il s'agit d'un travail «sans fin», prenant du temps facturable, sauf si vous pouvez refacturer votre client pour cela.
Vous pouvez provoquer des problèmes d'incompatibilité avec les plugins qui s'attendent à ce que le noyau fonctionne d'une certaine manière - cela nécessitera des tests supplémentaires

Parfois, c'est 100% inévitable, mais je peux presque toujours trouver une autre façon de réaliser les choses ou de modifier les spécifications en raison du coût probable du temps passé à le faire. C'est juste un cauchemar de maintenance, et beaucoup de gens optent pour le hacking core, au lieu de chercher la bonne solution.

— Dan Smart
source